jaclaz

1st question: DEL del ? Semi-random hints: What happens on a normally booted Vista if you open a command prompt and simply give the command? DEL del /f /a /q "%SYSTEMDRIVE%\ProgramData\Microsoft\Windows\Start Menu\Programs\Startup\StartVista.lnk" Any error? Are you sure you have the privileges needed to perform the action? Can you create a "tag" file somewhere, not on %systemdrive% say in C:\temp and add to the command something like: (at the beginning) If exist C:\temp\tagfile.tag goto :EOF and something at the end like: If NOT exist C:\temp\tagfile.tag ECHO The REG tweaks have been applied > C:\temp\tagfile.tag And have another .cmd automatically starting from another link like: If exist C:\temp\tagfile.tag ( DEL C:\temp\tagfile.tag DEL /f /a /q "%SYSTEMDRIVE%\ProgramData\Microsoft\Windows\Start Menu\Programs\Startup\StartVista.lnk" ) jaclaz

Besides the need for an IMAGING program, like Acronis True Image, GHOST, or similar Commercial or Freeware programs like those listed here: http://www.911cd.net/forums//index.php?sho...c=16534&hl= NOT a backup one, and definitely NOT nlite, which is an "install tweaking" program, what you want to do is NOT as straightforward as you might believe. Divided in steps, you are going to: 1) Image one drive to another one, and boot from the new hard disk on the SAME machine 2) Transfer the new hard disk to ANOTHER machine and boot from it WARNING: Depending on current licence you have, what you plan to do might prove to be NOT legal and will however need to re-activate XP. Read here how the TWO procedures might be carried on: http://www.michaelstevenstech.com/moving_xp.html And how it is possible in case of problems repair a XP install: http://www.michaelstevenstech.com/XPrepairinstall.htm PRINT the two articles, read them thoroughfully, re-read them, make sure you fully understand the procedures, DO NOT introduce variations, if anything is not clear, or you need to do something even SLIGHTLY different from the tutorials, ask for help BEFORE. On the other hand, if the question was if nlite can be useful to produce a slipstreamed install CD with same level of SP (and possibly KB updates) that can be used to perform the repairs, the answer is YES. jaclaz

Cannot say, I never used it, WHATEVER it is called Try this: @ECHO OFF ::fix_bini.cmd ::Small batch to make a BOOT.INI ::by jaclaz ::The following might need to be changed: Set drive=C: Set windowsdir=WINDOWS Set rdisk=0 Set partition=1 :Check IF NOT EXIST %drive%\%windowsdir%\explorer.exe GOTO :Error ::WARNING! ::DO NOT EDIT BELOW LINES - CHANGE VARIABLES ABOVE INSTEAD ATTRIB -H -S -R %drive%\BOOT.INI IF NOT EXIST %drive%\BOOT.$$$ COPY %drive1%\BOOT.INI %drive%\BOOT.$$$ >NUL ECHO [Boot Loader]> %drive%\BOOT.INI ECHO Timeout=0 >> %drive%\BOOT.INI ECHO [Operating Systems]>> %drive%\BOOT.INI ECHO Default=multi(0)disk(0)rdisk(%rdisk%)partition(%partition%)\%windowsdir%>> %drive%\BOOT.INI ECHO multi(0)disk(0)rdisk(%rdisk%)partition(%partition%)\%windowsdir%="Windows XP Professional" /noexecute=optin /fastdetect>> %drive%\BOOT.INI ::DO NOT EDIT ABOVE LINES REM ATTRIB +H +S +R %drive%\BOOT.INI GOTO :EOF :Error SET Choice= CLS ECHO An installation of Windows was not found on given path %drive%\%windowsdir% ECHO the batch has not performed any action, this could lead to an unbootable system ECHO Do you want to search for an install on another drive letter? SET /P Choice=(Y/N) IF /I NOT %Choice%.==Y. GOTO :Exit :Loopdrive CLS ECHO Please input another drive letter and press Enter: SET /P Drive= IF %Drive%.==. GOTO :Loopdrive Set Drive=%Drive%: GOTO :Check :Exit CLS ECHO An installation of Windows was not found on given path %drive%\%windowsdir% ECHO Exiting... PAUSE The above should have a very minimal error checking, what I would like to know is if it can work in the environment it is supposed to run, which I am not sure has all the features of a normal command prompt. Of course, once we are sure (as we should) that the drive letter is C: and that arcpath is multi(0)disk(0)rdisk(0)partition(1)\WINDOWS this would even be easier : ATTRIB -H -S -R C:\BOOT.INI ECHO [Boot Loader]> C:\BOOT.INI ECHO Timeout=0 >> C:\BOOT.INI ECHO [Operating Systems]>> C:\BOOT.INI ECHO Default=multi(0)disk(0)rdisk(0)partition(1)\WINDOWS>> C:\BOOT.INI ECHO multi(0)disk(0)rdisk(0)partition(1)\WINDOWS="Windows XP Professional" /noexecute=optin /fastdetect>> C:\BOOT.INI ATTRIB +H +S +R C:\BOOT.INI (as said elsewhere, though "substituting" a string is the CORRECT way to go on, the QUICKER one is to rewrite from scratch the entire file, if it's a 5 liner...) jaclaz

@ilko_t About boot.ini, wouldn't a good old batch file be more than enough? I normally run Win2K, coming with experience on NT4, never used bootfix.bin in my life, just the old way with batches, here are some examples, but of course we need to modify them according to our needs, it won't be difficult once I understand what they are. http://www.msfn.org/board/index.php?showtopic=66101&hl= One could easily search for a "tag file" like a file that is only in %windir% on all drives, and prompt the user to confirm the entry or entries. Just let me know which "features" are required. Yep, that's perfectly normal, as, as seen in the case you posted, the real size of the stick differs from what is "declared" or at least from what Windows can "see". To calculate the percentage of progress, rather obviously the programmer needs to calculate in "real time" the amount of data transferred divided by the total amount of data, the algorithm Roadkil's Disk Image uses is something like (in VERY "pseudo"code): set source=source set dest=dest set SOURCESIZE=getsourcesizeinsectors(source) Set N=1 :loop If exist source\sector(N) do Copy source\sector(N) dest\sector(N) else goto :end display progressbar(N/SOURCESIZE) goto :loop :end So, when N becomes bigger than SOURCESIZE, the number displayed becomes bigger than 100%, and it is probable that there is some check control that throws an error because the program thinks it has copied more data than available. I would be curious about a comparison between image size results coming from the use of Roadkil's, Acronis and with dsfi/dsfo, part of the DSFOK toolkit: http://members.ozemail.com.au/~nulifetv/freezip/freeware/ (command line, but VERY accurate, that, not having the check hypothized above, does not throw any error) 2,046,820,352 should then be the "real" size of the stick, this corresponds to the CHS end address of 248/216/31, this means that maybe, instead of "topping" to MaxCyl, the (wrong) partitioning simply takes 1 off BOTH NumCyl and NumHds. On a different geometry, like Nx128x32, End address of 2,046,820,352 would be exactly CHS 976/0/32, i.e. a "correct" Head boundary one. The maximum "correct" CHS address in a 248x255x63 geometry remains however 247/254/63, which leaves you with 2,046,820,352-2,039,837,184=6,983,168 bytes or 13,639 sectors not accessible/unused. No need to patch the MBR, all the "fun" happens in the bootsector, as cdob pointed out. If I am "allowed" to use dsfi/dsfo above, I can put together a small batch file that: 1) gets the bootsector from the stick and makes a copy of it 2) patches the copy so that it is invoking SETUPLDR.BIN 3) adds an entry in boot.ini directly chainloading the modified bootsector I have used similar batches in the past, they work for both FAT16 and FAT32, using it for NTFS might need some more work, but the USB device is normally FAT16 (or 32) anyway, isn't it? jaclaz

Here: http://www.msfn.org/board/index.php?showto...1384&st=199 Do review the thread, a few pages before there is more info about SATA drives, in a previous tutorial. jaclaz

@ilko_t Here is what I have found: No differences are found between BootSector_USB_Before.dat and BootSector_USB_After.dat. Both are FAT 16 bootsectors with 63 sectors before and partition length of 3997633 sectors. The stick appears to have a CHS Geometry of 248x255x63. MBR_USB_Before.dat appears to be a MBR written with the "HP" utility, check this thread here for a very recent discover on how and why (maybe) the MBR written by the HP utility is different from the "standard" NT/2K/XP/2003 one: http://www.boot-land.net/forums/index.php?...=2246&st=15 MBR_USB_After.dat is a "standard" NT/2K/XP/2003 (English). MBR_USB_Before.dat has a 0E (FAT 16 LBA) partition ranging from CHS 0/1/1 to 247/254/63 with LBA StartSector of 63 and Numsectors 3997633. MBR_USB_After.dat has a 0E (FAT 16 LBA) partition ranging from CHS 0/1/1 to 247/215/31 with LBA StartSector of 63 and Numsectors 3997633. Now, in CHS->LBA translation, on a "normal" Nx255x63 Geometry, 0/1/1 is sector 63, so the StartSector in BOTH MBR's is correct. On the contrary, both Numsectors appear to be incorrect, 247/254/63 in CHS->LBA translation is sector 3984119 thus Numsectors is 3984057, and 247/215/31 is sector 3981630 thus Numsectors is 3981568. Going the other way round, Numsectors 3997633 correspond to CHS address 248/215/31. (248 is a "wrong" value, as it is one Cylinder more than the total number of Cylinders that range from 0 to 247) So, it appears that the "HP" utility defaults to the Max Cylinder, Max Head and Max Sector (247/254/63) and writes the LBA independently, whilst Windows Setup or whatever wrote the MBR_USB_After.dat gets the right End Head (215) and End Sector (31), and tops the End Cylinder to Max Cyl (247) getting 247/215/31 instead of the "theoretically coorect 248/215/31. Some details of the "queer" way of CHS to LBA conversion and viceversa, and their effects can be found on my page: http://home.graffiti.net/jaclaz:graffiti.n...B/USBstick.html If you get Roadkil's Disk Image: http://www.roadkil.net/DiskImg.html and make an image of the stick, you will most probably find that the image has a size of 2,046,788,096 bytes, i.e. 3997633+63=3997696 sectors x 512 bytes/sector. If you find another size, I would like to know it. Good work with latest tutorial! Just as a reminder, cdob's MkMigratgeInf.cmd (GOOD work) needs (of course) to be run from within a 2K/XP/2003 system. Even if I have NO idea why it could become useful, the data to build MIGRATE.INF.TXT can be found in the MBR of the stick, see here: http://www.911cd.net/forums//index.php?showtopic=19663 If I get it right, with this latest one, since there is no drive "exchange" grub4dos is only needed to chainload setupldr.bin. If you think it might be of use, I could follow cdob's idea and get from the FAT12 bootsector of the first of the install floppies the code for invoking setupldr.bin instead of NTLDR and prepare an easy way to patch any FAT16 or FAT32 bootsector (for NTFS it might prove to be tricky). We could use a NTLDR and add to it an entry to direct chainload such a patched bootsector. Of course the above would limit the amount of (possible) multi-booting capabilities of the stick, but will eliminate the need for GRLDR and menu.lst. Also, I am not sure I have fully (or correctly) understood the need for multiple BOOT.INI entries, pointing to rdisk(0) and rdisk(1) and to partitions 1, 2 and three on them. I am sure we can find a way to generate on-the-spot a correct BOOT.INI. For the record, BOOT.INI has no need to be marked as System, Hidden, Read Only. jaclaz

Well, actually it is not my method , it was just a quote from a recent grub4dos readme.txt. Changing the post above to better make this clear. jaclaz

If it was so easy, would you think that a few people are fighting this battle since months without need? However a working solution has been found, do check this thread: http://www.msfn.org/board/index.php?showtopic=61384&hl= First tutorial (with reported success) here: http://www.msfn.org/board/index.php?showto...1384&st=128 Second one here: http://www.msfn.org/board/index.php?showto...1384&st=178 First thing however would be to make sure you can boot from THAT USB device on THAT computer, try using the HP utility, read the FAQ here, expecially #4 and #10: http://home.graffiti.net/jaclaz:graffiti.n...SB/USBfaqs.html jaclaz

Hmmm, at least officially, the first version is C, aka 4.72.XXXX Reference: http://www.msfn.org/board/index.php?showto...49626&st=22 jaclaz

Yep, also if you write (without the underscores): [_quote_] This is a quoted sentence. [_/quote_] you get: but if you write (again without the underscores) [_quote=jaclaz_] This is a quoted sentence, and the author is shown between parenthesis. [_/quote_] you get: jaclaz

Not much, but FYI: http://www.boot-land.net/forums/Recovery-Console-t2254.html Hmmm, cannot say, you could try using direct mapping of the image (it must be contiguous) instead of --mem mapping, but most probably the BSOD happens when the Windows driver "kicks in" and finds No device or a non supported device. Supposing that I can be defined "a more experienced grub4dos user", I am willing to try and help, but I am failing to understand the situation in it's entirety, can you please re-describe this second approach? What I got: on the root on the stick there is: grldr menu.lst as follows: title boot.ima map --mem /boot.ima (fd0) map (hd1) (hd0) map (hd0) (hd1) map --hook root (fd0) chainloader (fd0)+1 rootnoverify (fd0) map --floppies=1 boot a super-floppy image "boot.ima" containing: (ntldr above is really SETUPLDR.BIN renamed as ntldr, right?) the "RAMLOAD.IMG" contains: a dirtectory \I386 containing all files from \$WIN_NT$.~BT\ + txtsetup.sif + hiveOEM.inf A typo here?: And grub4dos boots in such a manner that SETUP assigns C:\ to the boot.ima file? Is the above correct? No need to use XP embedded tools, using VDK.EXE instead of IMDISK it is possible to create and format a full hard disk image (as opposed to single partition image) howto is here (as Trick #3): http://www.911cd.net/forums//index.php?sho...19056&st=49 If you give me the exact size (in bytes or in 512 sectors) I can prepare a correct MBR and write a few lines of batch to create and format such an image or, alternatively, create such an empty image and send it to you zipped. jaclaz

If I may, given for sure that #4 is the real missing thing, as Nuhi himself stated, as I see all other ones as not needed/unuseful, but although maybe posed in the "wrong" way, #2 has it's merits. Maybe something similar could somehow be implemented WITHOUT bothering Nuhi, that I guess has better/more important things to do, keeping nlite and now vlite working and up to date must be a hell of a work , by some cumulative effort. What if we find a way to "publish" some "pre-made" lastsession.ini files with a few different "levels" of component reduction? That would be the exact counterpart to the "levels" Silvereyes referred to (by the way the app is obviously 98lite and can still be found on it's homesite: http://www.litepc.com/ ). What we need is a kind of "standard" facsimile with a list of major functions or group of functions with checkboxes to have an easily readable documentation, easily comparable, to let the user know exactly or however with good approximation what features will have the build with each given lastsession.ini, and thus choose which "level" better reflects his needs, even if no "level" corresponds perfectly to the user "Optimized" ones, it would however be easier to "interpolate" settings between two "levels" rather than starting from scratch. For example this: http://www.msfn.org/board/index.php?showtopic=85456 could be the "Bare-minimum" level... What do you think of this? jaclaz

NT4 came with NO native CardBus (32 bit PCMCIA) support anyway. There used to be commercial third party Cardbus drivers/stacks, I guess that they are all discontinued by now, but since you don't have the hardware, that's allright. 48 Mbyte of memory seems a bit under-powered to me for NT 4.00: http://www.msfn.org/board/OS_laptop_t55146.html&st=5 that kind of machines usually had windows 95 on them. Back to your problem: Most probably nothing, but, once said that it is of course not recommended/possibly not working using driver files made for other devices, if you are positive that the card is the same or "nearly" the same, a possible path could be: 1) Get the Win2K drivers for your card 2) Get the Win2K drivers for the "other" card 3) Get the NT4.00 drivers for the "other" card Compare the .inf files of #2 against #1. With some common sense (and a bit of luck) you can find what changes between #2 and #1 can be "translated" into a hacked #3 .inf file, with some more luck it will even work . If there is nothing of note in the .inf files, it is possible that there is something in the actual binaries, this might prove to be more difficult to find, but the above hinted method should apply as well. I haven't checked, but if I am not mistaken the D-Link DWL-650 came in several releases, possibly with different versions of the Prism chip, you sure about that one you found using the same one? To find some "similar" cards, you may refer to the Linux list of "supported" PCMCIA/Cardbus: http://pcmcia-cs.sourceforge.net/ftp/SUPPORTED.CARDS (cards that use the same driver should have the same or however compatible chipset) Or, better yet, this one where chipset info for each card is clearly available: http://www.linux-wlan.org/docs/wlan_adapters.html.gz jaclaz

@snowden the problem is not actually in the bootsector, as said it is very easy to rename setupldr.bin to NTLDR and load it with a "normal" bootsector. The way (direct with renaming, grub4dos or other bootmanager, custom written bootsector) is irrelevant. Problem is the way the actual install process "detects" having NOT being booted from CD-ROM. If you want to experiment a bit, Gray on 911CD forum explained how to hexedit setupldr.bin so that it will use files on \I386 even on hard disk (or stick): http://www.911cd.net/forums//index.php?sho...3784&st=249 Possibly using this approach (and optionally using the Dietmar's modified NTDETECT.COM) could lead to some result. Another possible thing one could test (again FAR above my capabilities) would be to use some kind of "upper filters" or something similar to a modified dummydisk.sys driver: http://www.911cd.net/forums//index.php?sho...181&st=1954 to trick, at least the GUI part of setup to believe files are on a CD-ROM. Finally there is this (rather apodiptical, if I may) post by Disabled Trucker, that got NO followings: http://www.msfn.org/board/boot_install_USB...html&st=104 About the use of a PE environment as said my best bet is on a VERY minimal build, the Winbuilder project has gone as low as 15 Mbytes for a really minimal booting environment with CMD.EXE as shell, since all we need to do is to properly run WINNT32.EXE my guess that a not much bigger build would be needed. I tried to start something out of it, here: http://www.boot-land.net/forums/index.php?showtopic=644 but as often happens, everyone agrees, and noone actually does anything to contribute. However the Winbuilder projects have recently entered a more stable level, and a lot of refining work has been made, so I am still ( maybe optimistically) convinced that someone will soon take the challenge and hopefully deliver some results. jaclaz

If you need a simple one, do have a look at this: http://www.rejetto.com/hfs/ jaclaz

Yep, never said it was faster! All the idea of trying to find other methods was behind the fact that that method wasn't perfect. The link you posted does not work, a "tentative" list of possible methods is here: http://www.msfn.org/board/Installing_Unatt...8.html&st=6 Are you referring to method #3? Nothing has been done for a long time, but do have a look at it, the original thread is here: http://www.911cd.net/forums//index.php?showtopic=17425 I am quite sure that it would be possible to write from scratch a somewhat smarter "loader" or "setup" program running under DOS for 2K/XP, or somehow modify the original files as you suggested, but I am afraid it is far above my capabilities to contribute anything useful on that. Most probably there are some other possibilities, for example finding a way (HXdos?) to run WINNT32.EXE instead of WINNT.EXE on a DOS based OS booted from the stick could resolve the problem of the ~BT folder using the /makelocalsource switch pointing to the HD.... ...or finding a way to boot from the .ISO image of the CD saved on the stick.... Every idea, suggestion and contribution is welcome, even if it eventually it leads to a dead end, every attempt helps understanding something more about the way install works and hopefully will make new ideas/methods come to mind. jaclaz

I have been a few days away and I find that a lot of things have progressed. Congrats to both ilko_t and wimb! @ilko_t I had a quick look at your MBR files, as soon as I have time i'll take a closer look and post my findings. I can see it, it's the first post in USB booting subforum:http://www.911cd.net/forums//index.php?showforum=37 I am afraid your post is not present anymore. Some days ago I visited the CD Forum and was able to read your post there, but now the 911 CD part of the CD Forum is almost empty .... Regards, wimb wimb, he thread you are referring to is this one: http://www.911cd.net/forums//index.php?sho...c=19731&hl= (exactly as ilko_t originally referred it to be) As a general rule, always reference to a thread by it's ID rather that the page where you have seen it listed, posts may be moved around, particularly the 911CD forum has made a new subforum dedicated to USB booting, so posts are being moved from less relevant areas and put in the new one. @snowden As said before, there is the alternate method here using winnt.exe: http://www.911cd.net/forums//index.php?showtopic=16713 that of course does not create the "the ~BT folder onto the usb stick itself" and that can easily be fully automated via batch file. Moreover, as hinted here, it has the advantage of keeping install files on HD: http://www.msfn.org/board/I386_folder_t98414.html @buseeliu I don't get it , you join the board and post here just to say: "Look guys, your method is not good, too difficult, I have no alternate solution, so I cannot help, just wanted to let you know that I am looking for another way?" jaclaz

AGAIN, Grub cannot chainload directly XP, grub4dos can: http://grub4dos.jot.com/WikiHome Alternatively to the method illustrated here, it is possible to insert grub4dos inside Vista bootmanager, or to chainload the Vista Bootsector. All the above is related to grub4dos, NOT grub. jaclaz

For those interested, a link to the "original" thread: http://www.msfn.org/board/Data_recovery_tool_t84345.html jaclaz

For the record, to copy the \I386 directory from CD to the hard disk is a common practice between techs, since NT 4.0 days, it allows for two rather distinctive advantages: 1) installing from hard disk is faster (due to the inherently faster access rate of the HD when compared to CD) 2) should some more files be needed at a later stage, they are all already on the hard disk, so the user (EXPECIALLY of laptop PC's) will not be prompted to "Insert the Windows installation CD" when some driver of other file are found missing. I guess that most OEM installed systems use this method as it greatly simplify remote assistance. With the release of the various Service Packs and Windows Update, the 2nd part of the advantage has of course lost much of it's appeal, unless one makes periodically a slipstreamed-with-all-updates new source and copies it on the hard disk \I386 directory. WHY some means to automatically update or "slipstream" BOTH source installation files and actually installed files it has not being provided still remain one of the biggest Microsoft "misteries". As anyone trying to repair a system that has been updated by means of an "original" not-slipstreamed CD has experienced, it is nearly impossible, your best bet is to have another computer either online and with a fast connection or an archive with the various OS and SP's and burn on-the-spot a CD with the corresponding level of update as the system under repair. jaclaz P.S.: and yes the name comes from the old NT (cannot say if 3.1 or 3.51) CD where there was a \I386 directory for "Intel" based machines and one for "Alpha" ones, and of course the 386 was the first Intel processor to be able to run (maybe the verb "walk" would be more appropriate) the NT code, 32 bit, more properly defined as "IA-32" or "x86-32" family of processors: http://en.wikipedia.org/wiki/IA-32 http://en.wikipedia.org/wiki/Intel_80386

Geodisk appears more like an interface to standard Defrag/Scandisk than an actual "Third Party" defragger, so I guess that you need the ME version of the files anyway. jaclaz

Yes, it seems that at the time of releasing Win3.x Microsoft decided that it should run only with MS-DOS 6.22 (they had a lot of "pressure" at the time from DR-DOS) so the 3xstart is needed. Some details here http://www.911cd.net/forums//index.php?sho...16754&st=31 some interesting little apps/betterings for Win3.x can be found on the same thread: http://www.911cd.net/forums//index.php?showtopic=16754 jaclaz

On some motherboards, capable to boot to "super-floppy" type of device it is possible. You need to format the key WITHOUT a MBR. This way you would of course loose the capacity to boot from motherboards that NEED "HDD" formatting (with MBR). The only possible exception is the "special" MBR/bootsetor that makebootfat has, check here for some details: http://www.911cd.net/forums//index.php?sho...13784&st=44 http://www.911cd.net/forums//index.php?sho...0806&st=134 If the problem is just drive lettering, depending on WHICH OS you are going to boot from the stick there might be other solutions. jaclaz

A small correction, if you don't have a hub you will need a crossover or "patch" cable: http://www.littlewhitedog.com/content-8.html ("normal" cables are "direct" or "straight through") jaclaz

If you just quick formatted the drive, you should try TESTDISK, before anything else: http://www.cgsecurity.org/wiki/TestDisk In other words, what you should attempt first thing after a format is a Partition recovery instead of a file recovery. jaclaz