emendelson

Thank you! I guessed that the answer was simple, but I simply didn't know what it was. Perfect!

What I'm looking for is a drive letter that is NOT currently in use, so that I can assign it as a drive letter in a DOS emulator (DOSBox or vDos), which is why I needed = INVALID.

This should be obvious, but I can't find the answer anywhere. I have a For...Next routine that counts from ASCII 65 to 90 to find free drive letters, starting with A: and ending with Z: Is there a way to make it count down from 90 to 65, so it will start with Z:?? This is the code I use: For $x = 65 To 90 If DriveStatus(Chr($x) & ':\') = 'INVALID' Then $firstFree = (Chr($x) & ':') ExitLoop EndIf Next Thanks for any advice. Again, I think the answer should be obvious, but it isn't obvious to me.

Thank you for this. I didn't know it was even possible. It didn't work, possibly because RunWait doesn't seem to use parameters. So I tried: RunWait(@ComSpec & " /C " & $vDosTmp & ' ~ ARM64VERYSTRICTEXECUTION', $temp, @SW_MINIMIZE) But that didn't work either. The least bad thing I can think of is to write the registry entry and then delete it after running the command, in order not to clutter up the registry, but your method would be better if I could figure out how to make it work. EDIT: As far as I can tell from online sources, the command-line parameter won't have any effect. The only way to make this work seems to be through the Registry. Of course I could be wrong about this, and any information will be welcome.

I think the answer to my question is something as simple as this: RegWrite("HKCU\Software\Microsoft\Windows NT\CurrentVersion\AppCompatFlags\Layers", "C:\path\to\vdos.exe", "REG_SZ", "~ ARM64VERYSTRICTEXECUTION") Not tested in a script, but this is what I found in the Registry.

Like this: FileInstall("d:\dropbox\vdosinst\AutoItScripts\vdosbase.exe", $temp & "\vdos.exe", 1) If @error = 1 Then ShowError(51) $vDosTmp = ($temp & "\vdos.exe") RunWait($vDosTmp, $temp, @SW_MINIMIZE) $temp is a folder in the user's %TEMP% folder. ShowError() is a function that displays the error number.

I have a script that runs the vDos.exe DOS emulator. This works perfectly on Intel machines, but on ARM systems, vDos.exe needs to have "Strict compatibility" set in its Compatibility options, available from the Properties dialog. Is there a way to set the compatibility options from an AutoIt script? I've searched the forums without finding anything.

That is almost certainly the answer. Apparently Wine sets some variables that I should be able to test. I should have thought of this myself. Thank you! EDIT: There are about a dozen relevant variables: WINELOADER, WINEUSERNAME, etc., etc., This should be easy. Thank you again.

I don't think so, because the user can set Wine to report itself as any Windows version, with the matching build number.

I have some compiled scripts that cause problems if they run under wine on linux. I think I can work around the problems, but only if the script can detect that it is running under wine, and not real Windows. I've searched the forum without finding a technique for detecting wine. Am I missing something obvious? Thanks for any help.

I'm working on a script that uses image files (.img) in the FAT format, created by the IMGMAKE command in the DOSBox-X DOS emulator. PowerShell won't mount these files; I can open them in WinImage, but I'm trying to find a way to mount them as a drive letter in Windows so that I can copy or delete files on the image. Is there a way to do this through AutoIt? The closest thing I can find is the ImDisk driver, but it needs to be installed in Windows, and I want this script to be usable on other people's systems. Thanks for any help.

@Nine - Yes, VERY nice. Thank you...

@Andreik That works perfectly. Thank you.

I'm writing a script that uses DOSBox-X to run Windows 98 in a DOSBox-X window, and I want to be able to send a key to the Windows 98 desktop when it opens. If I use WinWait to wait until the DOSBox-X window opens, it detects the window while the Windows 98 system is still starting up. After the Windows 98 system starts up, the window size increases from 640x480 to 1024x768, and that is when I want to send a keystroke. Is it possible to wait until a window is a specified size? Or is there some other way to accomplish this? Thanks for any help. EDIT: I think the way to do this may be to repeat WinGetPos until the width and height match what I'm looking for, but if there's a more efficient way, I'll be grateful to know about it.

Yes, that seems to be the current best. Thank you!

Is there any hope that this code can be updated to replace the obsolete `_StringEncrypt` function? I've tried a few things without success.

... and I see that this was thoroughly discussed earlier: Apologies for not finding this earlier.

Further details: This routine at the top of a script makes it possible for the end-user to extract the source, by changing the name of the executable so that it includes "extract": ; make sure to include this in the directives at the top of the script: #AutoIt3Wrapper_Res_SaveSource=y ; then add this near the top of the source so the user can extract the source #include <FileConstants.au3> #include <MsgBoxConstants.au3> #include <WinAPIFiles.au3> ; https://www.autoitscript.com/forum/topic/162499-resourcesex-udf #include <ResourcesEx.au3> If StringInStr(@ScriptName, "extract") Then $Manifest = _Resource_GetAsString(999, 10, 2057, @ScriptFullPath) $hSource = FileOpen(@ScriptDir & "\" & @ScriptName & "-source.au3", 1) FileWrite($hSource, $Manifest) FileClose($hSource) Exit EndIf Is there a size limit for the Manifest? I can make this work in some of my scripts, but not in at least one that's much longer than the others.

I used ResourcesEx.au3 recently at the suggestion of @Jos. I had to add this line to prevent it from causing an error: #include <WinAPI.au3> Perhaps the code could be updated? Or am I wrong about this?

@Jos- To continue: ResourcesEx.au3 gave an error until I added this to the code. #include <WinAPI.au3> I'll post a message about that on its thread.

Thank you, @Jos! That definitely works, thought I had to add an include line to ResourcesEx.au3 (I added five at once, and clearly one of them worked - I'll sort out which one it was and post something in the thread about it.) Now my next job is to figure out how to make this available for the user from my actual script - maybe as a command-line option. I'll have to experiment to see if the script can extract its own source code. Again, thank you!

One thought: is it possible to write the script so that a user could use a command-line parameter to the program that would extract the source?

Yes, this directive: #AutoIt3Wrapper_Res_SaveSource=y It's the same option that SciTe puts on the Compile->Resource Update tab, where you can check a box that says "Save a copy of the Scriptsource in the output program resources." Again, just to be one-hundred-percent clear: I am talking about making my own code - the code that I wrote - available to an end user, NOT trying to extract someone else's code.

I compile some of my executables with the option to include the source code in the program resources. Is there an easy way for an end user to extract the source code? The answer is probably obvious, but I can't find it, and will be grateful for any pointers. EDIT: To be clear: I'm talking about my own code that I want to make available to other users. I am NOT, repeat NOT, asking about decompiling someone else's code. I am asking about how to give the user access to the script that I wrote and that I want to share, using the option built into the AutoIt compiler.

Ah! You are right!! I had been experimenting with the Shift-F8 list of parameters in the SciTe editor. As you say, this will not be a problem in real life. Apologies for wasting bandwidth.