Leaderboard

Is added to the current Beta of AutoIt3Wrapper.au3.

Purpose (from Microsoft's website) The HTTP Server API enables applications to communicate over HTTP without using Microsoft Internet Information Server (IIS). Applications can register to receive HTTP requests for particular URLs, receive HTTP requests, and send HTTP responses. The HTTP Server API includes SSL support so that applications can exchange data over secure HTTP connections without IIS. Description There have been several times in the past that I wanted to either retrieve information from one of my PCs or execute commands on one of my PCs, whether it was from across the world or sitting on my couch. Since AutoIt is one of my favorite tools for automating just about anything on my PC, I looked for ways to make to make it happen. Setting up a full blown IIS server seemed like overkill so I looked for lighter weight solutions. I thought about creating my own AutoIt UDP or TCP servers but that just wasn't robust enough, Then I found Microsoft's HTTP Server API and it looked very promising. After doing a little research into the APIs, I found that it was flexible & robust enough to handle just about any of the tasks that I required now and in the future. So a while back I decided to wrap the API functionality that I needed into an AutoIt UDF file to allow me to easily create the functionality I needed at the time. It has come in very handy over the years. Of course it wasn't all wrapped up with a nice little bow like it is now. That only happened when I decided to share it with anyone else who could use it or learn from it. The example file that I included is a very granular example of the steps required to get a lightweight HTTP Server up and listening for GET requests. The UDF is a wrapper for the Microsoft APIs. That means to do anything over and above what I show in the example, one would probably have to have at least a general knowledge of APIs or the ability to figure out which APIs/functions to use, what structures and data is needed to be passed to them, and in what order. However, the UDF gives a very solid foundation on which to build upon. Of course, if anyone has questions about the UDF or how to implement any particular functionality, I would probably help to the extent that I could or point you in the right direction so that you can figure out how to implement your own solution. Being that this is basically an AutoIt wrapper for the Microsoft API functions, there's no need to create AutoIt-specific documentation. All of the UDF functions, structures, constants, and enumerations are named after their Microsoft API counterparts. Therefore, you can refer to Microsoft's extensive documentation of their HTTP Server API. The APIs included in the UDF are the only ones that I have needed in the past to do what I needed to do. If you would like any additional APIs to be added to the UDF file, please suggestion them. Related Links Microsoft HTTP Server API - Start Page Microsoft HTTP Server API - API v2 Reference Microsoft HTTP Server API - Programming Model >>> See screen shots and DOWNLOAD in the Files section <<<

I have a question. what is the -w- 7 parameters ? and why it is with '-' after w ... or refers to an older version of AutoIt and no needed any more ! screenshot: I did not find relevant information.

With all due respect, sir, I'm taking into consideration everything @jchd mentioned. I was merely explaining why I chose that strategy because I had never used data types before. However, in light of the suggestions made, I will undoubtedly endeavour to make it accessible to everyone by atleast attempting to understand how to manage various data types. Thank you for your suggestions. I will also take the Default Tablename method into consideration.

Thank you for this UDF, it is very helpful. I managed to exchange data with python: import os import win32com.client obROT = win32com.client.GetObject(Identifier) arData = lv_obROT("Data2Python_arData") but, I did not manage to achieve the same for C#. Does someone know, if this is possible or must I use this?

No the installer will only remove HKCR\au3_auto_file when it exists as I think that was used in the past. Any reference to it in HKCR\.au3. will remain.

From au3check.exe itself au3check -help

https://www.autoitscript.com/autoit3/scite/docs/SciTE4AutoIt3/au3check.html

Edit (placed on purpose in a new post) : I think the function _WinAPI_GetFileSize() as scripted just above would return a correct result only if the file size is < 4GB (maximum of Dword) so $aRet[0] will contain the correct file size. If the file size is > 4GB, then the high-order doubleword of the file size will be returned to the 2nd parameter of the function, e.g $aRet[2] which was scripted like this : "dword*", 0 Which means, if the file size is > 4GB, then we should take care of $aRet[2] AND $aRet[0] to calculate the correct size (!?) Reminder: Msdn notes when GetFileSize function succeeds : GetFileSize function Return value : If the function succeeds, the return value is the low-order doubleword of the file size, and, if lpFileSizeHigh is non-NULL, the function puts the high-order doubleword of the file size into the variable pointed to by that parameter. Maybe that's the reason why GetFileSize shouldn't be used and GetFileSizeEx should be preferred, as GetFileSizeEx deals in a simpler way when files have a size > 4GB . Also in Msdn words : GetFileSize function Retrieves the size of the specified file, in bytes. It is recommended that you use GetFileSizeEx. [...] Could a DllCall guru share his comments about this, especially the part $aRet[2] AND $aRet[0] discussed just above ? Thanks

Hi @ioa747, good question, maybe one of the developer (@Jos, @jpm) could answer this 🤞 , I don't know too. Thanks in advance, very interesting 😀 . Best regards Sven

You can't pass a string containing the filename as the handle. FWIW, check out FileGetSize and _WinAPI_GetFileSizeEx in the help file.

For me, everyone is the hero, the teacher. Thanks for always helping me.

As @Factfinder mentioned: Script compiled as 32-bit on a 64-bit Operating System To access 32-Bit Hive - HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node use: HKLM To access 64-Bit Hive - HKEY_LOCAL_MACHINE use: HKLM64 Script compiled as 64-bit on a 64-bit Operating System: To access 32-Bit Hive - HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node use: HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node To 64-Bit Hive - HKEY_LOCAL_MACHINE use: HKEY_LOCAL_MACHINE I normally use the following in my scripts: Global $g_sHKLM32 = @AutoItX64 ? "HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node" : "HKLM" Global $g_sHKLM64 = @AutoItX64 ? "HKEY_LOCAL_MACHINE" : "HKLM64" Global $g_sProgramFilesDir32 = RegRead($g_sHKLM32 & "\SOFTWARE\Microsoft\Windows\CurrentVersion", "ProgramFilesDir") ConsoleWrite("32-Bit Program Files Directory: " & $g_sProgramFilesDir32 & @CRLF) Global $g_sProgramFilesDir64 = RegRead($g_sHKLM64 & "\SOFTWARE\Microsoft\Windows\CurrentVersion", "ProgramFilesDir") ConsoleWrite("64-Bit Program Files Directory: " & $g_sProgramFilesDir64 & @CRLF)