MHz

Your concept of wanting a RunOnceEx that does the current user seems off track in my opinion. When RunOnceEx runs, the current user is logged on, and inherits the current user settings and the other goes to the all users. If you want programs to be shared as a current user for all concept, then you should look at installing from Cmdlines.txt. No one is logged in at that time. Each user will inherit a profile of their own for each program installed at this time. Shortcuts are created for any new profiles, etc. Seems to me, this is what you are asking for instead of using RunOnceEx?

I have never had an issue with UltraISO and entering the username and serial via registry. Export those values from the registry, import, and it will work.

OSA.exe would not be the problem. Having only 133 Mb on your systemdrive would be. You say you have 2Gb of ram. It will need to page to HDD space somewhere? Virtual memory is a must! Your page file will not survive on 133 Mb of space. You will not be able to defrag the drive. The OS is choking. Solution: start uninstalling some software, before the OS dies. Aleast 15% or considing the size of the ram especially that you should not go below 4Gb of available HDD space.

Can see the problem. Your picture shows "BitDefender 8 Professional Plus - Registration" as the title, but the script has "BitDefender Professional Plus - Registration". You are missing the 8 ?

Go here: http://www.microsoft.com/whdc/device/input/Scancode.mspx and download the Keyboard Scan Code Specification. Bit of an explaination can be found here: http://www.annoyances.org/exec/forum/win2000/n1019911460

Well, use a bigger /S then. It is a NSIS installer. NSIS recognize UpperCase switches only.

Your Welcome

Single or double quotes are both allowed in AutoIt use. I use singles as I find it convenient in usage. No shift key required to insert, running a Comspec line is easier to manage as doubling up quotes are not normally needed. For example: Run(@Comspec & ' /c "' & @ScriptDir & '\Autorun.exe" /s') Notice how I can easily insert the double quotes that Comspec may require for a long path easily within the single quotes. This makes the script easy to interpret.

Well, I would first consider it as a working directory issue. A path could be allocated to the command interpreter, to allow autorun.exe, to see with in it's own directory or you may need to specify in the AutoIt script of the current working directory. A solution in your AutoIt script could be Run(@ScriptDir & '\Autorun.exe', @ScriptDir) or you could go alittle more excessive with ; Backup the current working directory $directory = @WorkingDir ; Change to the script directory, if not already FileChangeDir(@ScriptDir) ; Run the executable with the working directory as the script directory Run(@ScriptDir & '\Autorun.exe', @ScriptDir) ; Restore working directory at end of script FileChangeDir($directory) Or you can type Start /? into a command interpreter window, and it will show you parameters to use, especially on the path parameter. I would try these concepts out before going any further. As I would consider that one of these would solve your problem, with fingers crossed.

Cannot access the best solution to your problem with the current information. Some questions need answers: Q. Disk Images\Disk 1. Is this a 1 cd compilation? Q. Is this a multi-boot cd? Q. Is Sims 2 loaded from files in a folder or a mounted ISO? Q. Is Sims 2 loaded from the Harddrive? Q. Is RunOnceEx running the game executable or AutoRunGUI.dll or ...? Q. Where is this AutoRunGUI.dll in reference to your RunOnceEx? Q. Where is this AutoRunGUI.dll in reference to your AutoIt script? Q. Is your RunOnceEx file a cmd file or a AutoIt script? Q. Could you post the part of the script that seems to be causing the issue. I could come up with more questions indeed... Simply put, too many questions to give any kind of solution currently. I do not know if you even need a find drive letter function, for what type of drive? or that you are presumably using a cmd file, so it would render it perhaps useless in your case? More informatiom would be nice.

Having better luck then me. I cannot even find a broken link, yet alone a working one to that.....software.

MakeISO should be possible to add. Not sure of the others at the moment.

1) Yes, "Execute with Parameters" supports .msi files. 2) "Start in" sets the initial working directory for the file being executed. Normally installers do not need this to be entered. When you look at the properties of a shortcut, you will see a "Start in" edit field. Some programs will not run, unless they have this Start in field, so they can see their support files. I believe MS Office is one that requires it. So If you execute "C:\Program Files\Office\WinWord.exe", the Start in may require "C:\Program Files\Office" to run, or perhaps another folder to have as it's working directory. Msi files are called with msiexec. The /i switch for installing msi files would be required. So you would use: /i | IAGREE="Yes" ADDEXPLORERTOOLBAR="" SETSEARCHENGINE="" SETHOMEPAGE="" /QB Above would br the same as if you typed in a command prompt: msiexec /i "Path\to\the\file.msi" IAGREE="Yes" ADDEXPLORERTOOLBAR="" SETSEARCHENGINE="" SETHOMEPAGE="" /QB Msiexec is always executed with "Execute with Parameters" as to executing msi files. Typing /? as a parameter and executing will show you the required parameters to use it. I will update the helpfile to help clarify that msiexec is called directly for msi files. Originally, Comspec was used, so the /i switch could have been left omitted. HTH

I noticed that Daemons Tools supports 64bit.

%WinDir% is old dated environment variable for the Windows folder. %SystemRoot% is the newer dated environment variable for the Windows folder. %WinDir% remains in use, to allow batch scripts to run on both NT and 9x systems. If you use an NT command script, then %SystemRoot% would be more suitable to use. I would expect all system environment variables to be available at the same time. Windows NT and Windows 2000 do not have a Windows directory, so %WinDir% would have been strange? They have WinNT folders instead, which may have prompted the change?

Just use Cmdlines.txt to execute the cmdfile, instead of DetachedProgram. OEMPreinstall does not stop Cmdlines.txt from executing. Cmdlines.txt will execute even without a Winnt.sif.

Contextmenu extension. Copy to... Move to... Windows Registry Editor Version 5.00 [HKEY_CLASSES_ROOT\*\shellex\ContextMenuHandlers] [HKEY_CLASSES_ROOT\*\shellex\ContextMenuHandlers\{C2FBB630-2971-11D1-A18C-00C04FD75D13}] [HKEY_CLASSES_ROOT\*\shellex\ContextMenuHandlers\{C2FBB631-2971-11D1-A18C-00C04FD75D13}]

Nice language, thanks for your kind response. But sometimes things are not possible.

Such a noob? I have been using this for about 5 years. Register means nothing. ****, forgot to wipe my.... with their great product. "****, this old stuff is boring me".

Boot into Safe mode and do it. You could remove the dllcache copy as well? This file seems to be a self-registering file, so if permanent removal was the consideration, then regsvr32 /u on it, comes to mind. The original file could be restored with sfc.

You could look at sc.exe ? sc.exe can delete and create a service.

Apparently the same time as RunOnce keys are processed. GuiRunOnce does not block the logon process, so you should have an active desktop, when the 1st installation has just has started it's installation routine.

It resides in the Interent Explorer Folder. It would deal with HTTP mail simple mapi.

That file is protected by Windows File Protection. You can delete it normally, but Windows will keep returning it. Unlocker will be useless for this, as handles are not the problem. You would need to disable Windows File Protection to remove it.

Yes, it is good for the beginners. I did state that previously? I do mention also of other options that people may not be aware of. The first tool that I would think of is AutoMacroGenerator, if I wanted an application to record a automated gui install with AutoIt. I use CMenu to do up silent installation scripts. I would use Au3Record for manipulating items on the desktop, that only a keyboard and mouse can manage. So, each of the said tools, have a different purpose of their capabilites. If you want to use any of these options to do unattended installations, then that is ok by me. There is a tutorial in the AutoIt help guide that shows you how to install Winzip. Once you have learnt to make use of the Win*() functions, and Send() etc. then you should have a look at the Control*() functions, as mentioned at the bottom of the page. Learning is about doing one thing at a time, so learning the primary functions 1st is a good way to go. So, this guide above is also a good place to start. But should be noted, as not the be all and end all of accomplishing installations with AutoIt. Once you can do installations manually written with AutoIt, then you should be able to do many more things with it. It is a very powerful language for scripting your everyday needs etc. A simple and basic guide, is good for the newcomers of AutoIt. This guide fits that need. So, nice work again, master_mtz.