jaclaz

Sure. This is EXACTLY the reason why telephone (and keyboard) sanitizers are such a pillar in our society, and the EXACT same reason why a more evoluted race like the Golgafrinchans would send them away on the "B" ark first: http://hitchhikers.wikia.com/wiki/Golgafrincham to only later discover their vital importance: http://en.wikipedia.org/wiki/List_of_minor_The_Hitchhiker's_Guide_to_the_Galaxy_characters#Telephone_Sanitizer jaclaz

And to be even pickier this can be also done in DOS/Windows9x/Me, using LetterAssigner, and this makes a nice loopback to: http://www.msfn.org/board/topic/118119-patched-iosys-for-9xme/ Sure , but while doing so, you named in vain the NT . jaclaz

Well, there are (just for the record) two kinds of USB Mice/Keyboards. One that is compatible (through an adapter) to PS/2 and one that it is not, if you have the latter type, they simply wont' work. More generally, you are describing a "haunted" system , though this is possible, I tend to believe not in voodoo, it is more probable that your system has some intermittent hardware issue. It is not uncommon, on old systems that *something* is simply "cooked up" or, even if each component is ok, that some contacts are not perfect. What I would do in your case would be to first thing disassemble the PC parts, clean the thingy from dust and reseat everything, then carry on some diagnostics, particularly on hard disk and RAM. If you have available (or can borrow) a PSU, it won't be such a bad idea to try the system with it, it happens that a "weared out" power supply starts creating every kind of issues, phantom devices and what not. The usual approach is to disconnect *everything* from the PC (non first hard disk(s), CD/DVD drives, add on cards, etc.) and test it, then re-add one by one any non-essential device. It is also possible that your OS have been partially corrupted, but it is less likely, judging from the *random* symptoms you reported. About directly logging in as said and AFAICR, the idea of Autologon is that the account is password protected but the password is provided automatically. You may want, instead of using the method(s) linked to, to use this: http://technet.microsoft.com/en-us/sysinternals/bb963905.aspx which is rather "user friendly" (besides making the password encrypted) There is a valid alternative solution through a component used in XP Embedded, called minlogon BUT it is not available/redistributable. And there is a way to disable the checking of the password completely, but it will behave more like a "Normal" user with an empty password, you will still be prompted for a password and you will have to click to login. jaclaz

To be picky (as I am ) there is also the fact about the drive lettering algorithm being slightly different "by design" in DOS and NT, just for the record: http://www.msfn.org/board/topic/35329-ever-wondered-why-xp-setup-changes-drive-letters/?p=243053 DOS: https://web.archive.org/web/20100820162832/http://support.microsoft.com/kb/51978 NT: http://support.microsoft.com/kb/93373/en-us http://support.microsoft.com/kb/234048/en-us and if you add to this the different volume ID's that the DOS and the NT can recognize, it is fairly easy on multi-hard disk systems or when there is any "non-floppy" or "non-harddisk" device connected (or even those connected through an interface that needs a driver in CONFIG.SYS) to have mismatching drive letter assignments. jaclaz

I believe (as I said earlier) that - at least from what you reported - you used ONLY PARTIALLY "Method 2" on the given MS KB: http://support.microsoft.com/kb/315231/en-us The idea of "autologon" AFAICR is that a password MUST be set (and then it is automatically provided at logon), I suspect that *somehow* you managed to set autologon with a blank password and this is the "root" of the issue. What about the BIOS password, did you solve that issue? jaclaz

They are WHAT? jaclaz

I must be missing something , but if you "fix" the path to: %~dp0subfolder\oem\ %~dp0subfolder\oem\runonceex\ in oem.cmd, you actually KNOW the path to \OEM\RunOnceEx\ and the whole exercise is vain, you can directly hardcode it to \subfolder\oem\runonceex\ in the "main" batch. I mean, the expected situation is this one: http://www.msfn.org/board/topic/173102-batch-search-file-in-all-drives-script-help-needed/?p=1090274 Of course putting the actual file in root of the drive (or in a fixed, known path) would be much more convenient (and much, much faster), but if the OP really wants this (more complex than needed BTW) setup, he will probably have his own reasons for it. One could even use a self-deleting batch in root, if the issue is about "cluttering" the root of the drive, but we miss a description of the actual "final goal" and the environment/reason why this is needed. jaclaz

I am failing to see why you are asking questions when you already know all the answers to them. jaclaz

I have to presume that you are missing the definition of the adverb EXACTLY. EXACTLY how many partitions are on the disk? Are they all primary, or some are primary and some are logical volumes inside extended, describe them EXACTLY? On WHICH EXACT CHS each of them starts and ends? EXACTLY how many sectors are in each of them? How big EXACTLY is the hard disk? etc., etc. Do yourself a favour , get the UBCD: http://www.ultimatebootcd.com/ and burn it to CD. Then use the RPM in it. I don't want to know where/how you found Partition Magic for download. Then (if possible at all) do follow the advice of making the first, active primary partition a small FAT16 partition, believe me when I tell you that it will save you a lot of headaches, before or later. Get also bootpart from here: http://www.winimage.com/bootpart.htm there is a reason why Gilles Vollant (besides yours truly) says: BTW as hinted earlier, it makes VERY LITTLE SENSE (unless you want some additional troubles) to install NT 4.00 on NTFS on a system that will dual boot with 2K or later, however, JFYI: http://www.msfn.org/board/topic/169500-chkdsk-refuses-to-check-ntfs-volume-under-windows-nt-40/ jaclaz

... and you have a broken Google Here : http://www.softpedia.com/get/System/OS-Enhancements/Change-File-Extension-Shell-Menu.shtml Obtained through : http://bit.ly/1yW41GG jaclaz

Which system is it? It is probable/possible that you are using a USB keyboard (ad mouse), the mouse should cause no issues, but it has happened that USB keyboards behaved "queerly" in the early parts of booting, if you have available (or can borrow) a PS/2 keyboard (and provided that the machine actually has a PS/2 port) you may try with it. And I wouldn't completely rule out a defective keyboard, so I would try with another one anyway. The fact that your system has now a BIOS password protection is not "good news", you may have accidentally set one, again, depending on which exact system (make/model) it is, it may be possible to clear that BIOS password or recover it. But this right now is not the "main" issue. jaclaz

There are two aspects on IDE vs. SATA. ALL of them depend mainly on the BUS/controller and on the actual hard disk. A "IDE" (actually ATA 133) has more or less the same speed as a SATA 1 (which tops at 150). Both normally "saturate" the speed of a rotational hard disk, particularly on a laptop where usually disks are "not that fast", SATA 2 being faster will surely saturate the HD speed, SATA 3 in practice makes only sense for SSD's or maybe for very high end disks, like 15,000 RPM ones, very unlikely to be on a laptop. BUT if the disk has NCQ, the SATA will become noticeably faster. See: http://www.msfn.org/board/topic/120444-how-to-install-windows-from-usb-winsetupfromusb-with-gui/page-24#entry884409 jaclaz

How EXACTLY did you partition the disk? jaclaz

Well, the result will be slightly different each time, and of course "afolder" will be listed before "xfolder". Hint: If you have any control on the first level directory, you'd better name it starting with "a" than with "z". The "hope" is that, on average, there are far more files on a system than directories and that this will speed up (a little bit) the execution, and that a "higher" level such as "\OEM\" will be reached faster than a "lower" one. You can try also with : :NEXT5ECHO %TIME%FOR /F %%A IN ('DIR /B/S/OG %drive%\%rootfolder%') DO IF EXIST %%A\%partfolder%\%file% ECHO !TIME! FOUND %%A\%partfolder%\%file%& GOTO :NEXT5jaclaz

Which version of the command is faster? (they should ALL work). In my quick tests ":NEXT4" seemed slightly faster, or, if you prefer, I tentatively set in a "slower to faster" order in the batch. Using the IF EXIST should also represent an added "check", if the .cmd file will end up named with a rather common name, to avoid "false positives" or "filename collisions". jaclaz

What about "porting back" the info that the good FreeDOS guys have put together? http://www.freedos.org/wiki/index.php/Networking_FreeDOS_-_NDIS_driver_installation I would also look here: http://toogam.com/software/archive/drivers/network/network.htm maybe (just maybe) the Windows for Workgroup thingy helps in configuring/fixing... jaclaz

This more or less amount to "Enable automatic logon" http://support.microsoft.com/kb/315231/en-us but you seem to have followed oNLY PARTIALLY "Method 2" This is "strange". Maybe it is a timing problem, but pressing (sometimes tapping insistently) F8 should bring you to this: it is possible that the F8 key is also used by your BIOS to change boot device selection, if this is the case you should try again, starting pressing/tapping F8 only after the initial BIOS bootscreen. Try again, after having read this page: http://www.playtool.com/pages/safemode/safemode.html If you get to that screenshot, try selecting "Safe Mode". jaclaz

Good. Now, let's remove (temporarily) the looping into various drives, and let's limit the test to a single drive. Try your on your own setup (possibly do this on a "filled" volume). @ECHO OFFSETLOCAL ENABLEEXTENSIONS ENABLEDELAYEDEXPANSIONSET drive=C:SET folder=OEM\RunOnceExSET rootfolder=OEMSET partfolder=RunOnceExSET file=newtest.cmdECHO %TIME%FOR /F %%A IN ('DIR /B/S/AD %drive%\ ^|FIND "%folder%"') DO IF EXIST %%A\%file% ECHO !TIME! FOUND %%A\%file%& GOTO :NEXT1:NEXT1ECHO %TIME%FOR /F %%A IN ('DIR /B/S/A-D %drive%\%file% ^|FIND "%file%"') DO ECHO !TIME! FOUND %%A&GOTO :NEXT2:NEXT2ECHO %TIME%FOR /F %%A IN ('DIR /B/S/A-D %drive%\%file%') DO ECHO !TIME! FOUND %%A&GOTO :NEXT3:NEXT3ECHO %TIME%FOR /F %%A IN ('DIR /B/S/AD %drive%\%partfolder%') DO IF EXIST %%A\%file% ECHO !TIME! FOUND %%A\%file%& GOTO :NEXT4:NEXT4ECHO %TIME%FOR /F %%A IN ('DIR /B/S/AD %drive%\%rootfolder%') DO IF EXIST %%A\%partfolder%\%file% ECHO !TIME! FOUND %%A\%partfolder%\%file%& GOTO :NEXT5:NEXT5:OUTOFHEREECHO %TIME%You get the idea .The point is that (hopefully/maybe) making the list for only directories might be faster and compensate the additional IF exist. It is entirely possible that *somehow* Windows "caches" results of a previous DIR command , so each snippet should probably be tested "separately". jaclaz

Still, it would make IMHO things more "sound". Can you post a practical example of your (intended) setup? Maybe there is some more efficient way to look for the file(s) I mean, would something *like*: be faster than: And (still cannot say if more efficient) have you actually tried FORFILES? jaclaz

@Mike88 Depending on the real use of the batch, it would be much more convenient and "safe" to have the file on *any* drive BUT on a known path, like root or (say) \mytagfiles\ , depending on the number of files/directories/subdirectories on the filesystem the search for it could take a long time. The FOR /L loop assigns all valuee from 90 to 65 step -1. The EXITCODEASCII "translates" them to ASCII, 65 is A and 90 is Z. Some info on EXITCODEASCII is here, JFYI: http://www.robvanderwoude.com/ntset.php and here you can find a simple batch that uses it: http://reboot.pro/topic/2986-yacbfc-dec2hexcmd-and-hex2deccmd/ http://reboot.pro/topic/2986-yacbfc-dec2hexcmd-and-hex2deccmd/?p=136708 jaclaz

Which makes me not alone but rather in good company. Well said . jaclaz

All is well that ends well. Just for the record, as often happens, a "key" piece of info was missing initially (the fact that it was an "install from USB"), and I guess that having posted it here: MSFN Forum Unattended Windows Discussion & Support Device Drivers http://www.msfn.org/board/forum/88-device-drivers/ instead of: MSFN Forum Member Contributed Projects Install Windows from USB http://www.msfn.org/board/forum/157-install-windows-from-usb/ sent people looking for a wild goose chase, at least that happened to me , I was completely deceived by this issue that while it didn't at all look like a X,Y,Z problem, was actually a (slight) form of the X,Y,Z problem: http://homepage.ntlworld.com./jonathan.deboynepollard/FGA/put-down-the-chocolate-covered-banana.html jaclaz

Good, actually I said "seemingly" as I saw at first sight no /S switch in your DIR command, and did not take the time to actually read the batch, as it seemed to me much more complex than needed. Now that I have read it, please allow me to doubt (though it is possible) that a self calling batch sub will be faster that executing the command with a recursive switch. And now that I have, besides read it, it tested it, getting as result a: error on my XP, I can confirm that your approach is *somehow* not the best one. To replicate, try using it (slightly modified to look only on one disk and to provide some feedback) on a disk (say A:\ ) where "test.cmd" is in: root\Afolder\BUT with the actual batch residing in a directory on C:\ containing a number of directories.... @ECHO OFFSETLOCAL ENABLEEXTENSIONS ENABLEDELAYEDEXPANSIONSET /A Counter=0DIR /B /S A:PAUSESET FindFile=mytest.cmdSET FoundFile=NopeCALL :IsItThere "A:" %FindFile% FoundFileIF "!FoundFile!" NEQ "Nope" GOTO :FOUNDECHO ERROR: "%FindFile%" not found.PAUSEEXIT /b:FOUNDECHO File "%FindFile%" found in "%FoundFile%".ENDLOCALPAUSEEXIT /b:IsItThereSET /A Counter+=1SETLOCAL ENABLEEXTENSIONS ENABLEDELAYEDEXPANSIONSET Result=NopeIF EXIST "%~dp1%2" ((SET "Result=%~dp1")&GOTO :DONE)FOR /F "tokens=*" %%G IN ('dir /B /AD "%~dp1"') DO (IF !Counter!==6 GOTO :DONEECHO !Counter! "%~dp1" CALL :IsItThere "%%G" %2 ResultCALL :IsItThere "%%G" %2 ResultIF "!Result!" NEQ "Nope" GOTO :DONE):DONEENDLOCAL&(SET %3=%Result%)&EXIT /B 0This is what I get: If I copy mytest.cmd to root of A;\ I get: jaclaz

Well it is not like a TXTSETUP.OEM is a digitally signed encrypted file stored inside a passwod protected RAR file on a Truecrypt volume it's a plain text file and you can put together one easily. The readme.rtf on the given site talks of F6 floppy install, so seemingly it is just TXTSETUP.OEEM that is missing. See here: http://rmprepusb.blogspot.it/2013/06/txtsetupoem-files-for-f6-floppy-disks.html Use (say) this driver as a "base" reference: http://dlcdnet.asus.com/pub/ASUS/misc/utils/AMD_RAIDAHCIController_V25154039.zip This said, FORGET temporarily the above (it may become useful next time) and follow cdob's suggestion first. jacaz

Yep , the point on the other thread being (besides the nice sample by Yzöwl) that using DIR /S on a largish (possibly filled up to the brim) volume will be slow. If the volume is NTFS formatted, using a search tool parsing just the $MFT will result as waaaay faster. The suggested tool is MIA (but can be obtained through the Wayback Machine): http://web.archive.org/web/20130525223305/http://ndff.hotbox.ru/en/ And there is another nice tool here: http://reboot.pro/topic/18855-windows-file-search-utility-that-is-fast/ Just for the record, the bhplt example seemingly only looks for the file in root (which may or may not be what the OP wants)., and nowadays it makes little sense (unless there is a reason for it) to look for files in the A: or B: drive jaclaz