MHz

Normally, businesses are around, that can extract the info, from a dead drive. It may cost you, as you could imagine.

So long as you run the 2 OSes separate, no sharing programs etc, it is fine to do. I could speculate, and say that perhaps the Master File Table has currupted. 3rd party defraggers can defrag the MFT, and are known for corrupting the MFT, hope you do not use any of these. You should not write to this disk, in any way. You will need to use some HDD recovery software. I just googled, and found a free product. Not sure of it's expectation. Plenty of pay for types around. Hope it works out for you.

"::" is used by programming editors. Rem is also an alltime feature.

In Autoit, this will close the window, but if still exists, it will try for up to 5 secs. Just that sometimes, a second close message is required, in RunOnceEx. $title = "TheTitleHere" WinWait($title) For $i = 1 To 20 WinClose($title) If Not WinExists($title) Then ExitLoop Sleep(250) Next

Ok, use this Opt("WinWaitDelay", 100) It is normally 250. You should not quite see the window, before Autoit will WinMove() it. As djbe stated, move it off screen to the negative side, no resolution change problems then, it should be almost the closet to a silent install as possible?

That is Shutdown.exe calling the shutdown, not Alcohol. Should use: start /wait msiexec /i setup.exe /qn /norestart

-1 is a default value for interger, where allowed. "" is default value for strings, where allowed. This could be done. Are the windows that ugly? Are you meaning Silent Install by using Autoit? Try this modded USSF(including source). I just put USSF.exe on the desktop, and drag any setup.exe onto it. It should give you a report on the recognized installer, then give an option on a template Au3 script, which is extracted to the same directory as the setup.exe (or whatever setup.exe is called). Just replace any question marks, with the needed information. USSF with Au3 Silent Install Templates.4 templates only. Inno Setup, NSIS, Wise and MSI. With WinSetState(), you need to everytime. But WinMove(), the installer should remember it's position.

Run("SETUP.EXE", "", @SW_HIDE) If anything, this may hide the intial window. Though the success always seems low. A way of not showing what is happening, could be to WinMove() the setup window off screen. WinMove ( "title", "text", x, y)

The issue is NOT mainly about BUGS. Each time someone devises a way to attack, one needs to block. This is normal. If you want total blockage, then do not connect to the internet and do not accept other's disc's to your PC. If you know anything about programming software, and how people abuse this, then this is painfully obvious. Upgrades to software is a welcoming thought, I consider. Let's arise from shallow thought's, eh?

Upgrading and blocking security issues are normal events. If you do not want them, then disconnect from the internet, for 100% security and simply do not accept the OS upgrades. Hmm, you want support, Yes or No ??? And Linux has their own share of problems to sort out. Yes ???

Nice going. Let's see good, positive movement on them scripts. We are counting on super scripts from you.

X-Savior dismissed Xplode. Someone was trying to spoon-feed Xplode again? X-Savior has right of passage to object. @X-Savior, if you are really determined, learn a programming langauge to do what you want. Learning to do it yourself, rather relying on programs to do it for you, is a positive step. Someone mention Autoit, learning this will enable you, not only unattended stuff, but enormous abilities. Ofcourse, let's mention C++, VB etc. Why waste precious time on... Well, good luck on your choice.

One is not more stable than the other? Professional adds more options with HDD to use like Volumes, Group Policy settings, etc. You have to look at these features. It is what is under the hood that counts, as they say. A laptop with Home maybe sufficient? Has networking etc. just as good. Professional is my choice, as no limits, but if you do not have the knowledge to use already, then...maybe it is a waste of money?

Hard to interpret exactly by your explaination. But I would assume missing video codecs are your problem. A collection of codecs is compiled by swgreed. You could use his codec pack. Check this thread to download.

Incorrect memory timng incompatible ram or other, can give you different read bad spots each time. Only good memory is a good stick of memory. The switches you are mentioning, can also be set by MSConfig. This will not help you with bad ram. Bad ram memory corrupts data as it passes through it. This includes data during bootup, moving files from one drive to another, and so on. The question is. Are you willing to try some illogical software fix, for a problematic hardware failure? I know I would not. But the choice is yours. If it is not JEDEC standard ram, then compatibility with the motherboard could be a main issue of fault. Check your timings. Use Memtest86 to test it. Do up to 50 passes. If it gives an error, then lose the ram.

Remove the double quotes from the last line. Send($answer) Good luck.

One user in oobeinfo.ini has autologon. The autologon in winnt.sif, refers to the admin account, not your account. So you will normally set this to No.

I'm not sure of your circumstances, but consider downloading Scite4Autoit3. The new version has AutoMacroGenerator in it. This is a good tool for helping to create an install scripts. Upon entering your serial, ControlSetText() would be the function to use, to send the serial directly, into the edit control. ControlClick() may uncheck the msfn help files install. Good luck.

Only one user, this should work fine. [userInfo] Identity000="Joel Garner" Place this in $OEM\$$\System32\oobe\oobeinfo.ini

Instead of starting the executables directly. Start the shortcuts instead. The shortcuts contain the working directory information, that you may need to run them with.

Yup, probably does. Happy birthday. btw.

Have you tried Runas ? Just right click on the game shortcut and choose Run as... This will enable you to choose another account to run it under.

Interacting with controls directly, is normally more reliable though. Example: Run(@ProgramFilesDir & "\Autoit3\Autoit3.exe") WinWait('Run Script') ControlSetText("Run Script", "", "Edit1", @ProgramFilesDir & "\Common Files") ControlClick("Run Script", "", "Button2") It is all in the Autoit Manual.

In the above example, it will be perform correct.

Run(@ProgramFilesDir & "\Autoit3\Autoit3.exe") WinWait('Run Script') Send("Swimming Bird.au3")