Unfortunately, this is somewhat of a known issue. AutoIt and Windows 9x seem to have a whole lot of difficulty agreeing on the PATH, so I've been hacking awaay at various workarounds for the last few versions. You can read through this thread for some of my frustrations with this issue (also look for some of drugwash's previous posts - it sounds like he had the same issues). I'm going to continue to work on that when I have time, but Windows 9x is not officially supported, so this is a "when I have the time" kind of issue. thanks nitro for further investigating this topic.... i also tried to pindown the problem.... 'winset.exe' works... for instance, if start uniextractor with this bat: start.bat ''winset path2=%path%;c:\uniextractor;c:\uniextractor\bin uniextractor.exe winset path=%path2%'' ... the path variable is recovered succesful & not destroyed (but uniextractor is also not working.... :/) Avoid using "start" as a batch file name because it can conflict with START.EXE. The second line of your batch file should be "start /wait uniextractor.exe". I am able to consistently preserve the PATH variable on Win98SE, regardless of AutoIt error state, by running it from a batch file set to hide its window and output: univextr.bat: @SET PATH1=%PATH% @START /wait Uniextract %1 %2 %3 %4 %5 %6 %7 %8 %9 @WINSET PATH=%PATH1% @SET PATH1= Note that the first SET doesn't need WINSET because it's running in the local copy of the environment. The final SET (to erase the temporary variable) would not be necessary if you never run the batch file from within an existing command prompt, since it will be deleted when the local environment scope ends anyway. The %1...%9 are only there as a kludge to handle files dropped on the batch, and will cause dropped files to extract with an 8.3 filename. If you create a shortcut to the batch file, you can edit the shortcut properties to make the batch window open as a minimised button on the taskbar. Unfortunately, this system requires me launching UniExtract via the batch file (or a shortcut to it), and then dropping a file on the UniExtract window to work properly. I haven't attempted to modify UniExtract or the necessary registry entries to fix the right-click menu options. If UniExtract is run any way other than from the batch file, it will of course still clobber the PATH variable. This setup also does not address the problem of UniExtract announcing the following error after each run, despite successful extraction: -AutoIt Error - -Line 0 (File "C:\Program Files\Universal Extractor\UniExtract.exe"): - -if @OSType == "WIN32_WINDOWS" AND $oldpath <> " then runwait($cmd & filegetshortname(@scriptdir & '\bin\winset.exe') & ' path=' & $oldpath, -@windowsdir, @SW_HIDE) - -Error: Unable to execute the external program. - -A device attached to the system is not functioning. - -{ OK } It's worth noting, of course, that this error dialogue refers of course to AutoIt code that mentions winset.exe, not to the batch file's call to WINSET. This error dialogue occurs on 98SE regardless of whether the batch file is used or not. I am using Universal Extractor 1.5 on on Windows 98SE v. 4.10.2222 A with Unofficial Windows98 SE Service Pack 2.1a Reference: http://www.ericphelps.com/batch/samples/samples.htm
