jaclaz

Just for the record, the proper way to check for a directory should be checking for nul.ext instead of nul, at least on NT based systems, reference: http://xset.tripod.com/tip5.htm http://msmvps.com/blogs/martinzugec/archiv...-same-name.aspx It is a remote possibility that there exists a file with same name as folder, but you never know. jaclaz

Yes, "Commercial" programs should all have such a provision. Since, to be accurate, you do not actually need an image, but rather you only need to clone the disk, this Freeware one could be just right for your scope: http://www.miray.de/products/sat.hdclone.html#free http://www.miray.de/download/sat.hdclone.html The FREEWARE version is slower than the Commercial ones, of course, but since noone is chasing you, it might be worth at least a try, on the other hand, as it offers less options, it might be easier for a novice. I think it will only expand the OLD "small" partition to a "bigger" one, but I guess it will be allright, there are other programs to resize/create expand partitions, that you can use later. With reference to my previous post: Since your new HD is SATA and most probably you do not have a SATA interface on the old machine, the above won't be possible, you'll need to do something different: 1) Burn a bootable CD from the downloaded HDclone file, TEST it on BOTH the new and old PC to make sure it boots properly, do also test the "nlited" INSTALL CD, ideally you should try to install XP from THAT CD on the NEW machine (and later format the drive) to make sure that everything works as expected 2) "Prepare" the OLD IDE HD on the OLD machine by removing all devices from Device Manager, IMPORTANT do some preventive tries with just removing, say, the video card or PCI IDE driver and see if at next reboot it is redetected correctly, it is ESSENTIAL to be able to revert back if something goes wrong (one OLD working PC is still better than one non-working NEW one and definitely better than having two computers BOTH non-working). As soon as you are sure that the removal and re-detecting works (it is OK of a "standard" driver is re-loaded instead of the "specific" one, do the complete removal. Do read this (Win2k, but most can be applied to XP too): http://www.motherboard.windowsreinstall.com/win2k.htm with particular attention to solution #4 and #6 3) Shutdown the OLD PC and DO NOT RE-BOOT IT, take the IDE HD out of it. 4) Go to the new PC and MAKE SURE that in the BIOS boot order is setup so that CD boots first, if possible disable booting from ANY HD alltogether 5) Try once again booting from CD to make sure 6) Shutdown new PC and install on it the OLD HD 7) Boot from the HDclone CD and perform the cloning 8) Once cloning is over, remove HDclone CD, shutdown the PC and remove the old HD 9) Power ON PC, go in the BIOS and set it to boot from CD first then HD, insert the "nlited" CD (WITH the SATA drivers for the new PC or be ready with a floppy with the "F6" drivers) 10) Boot from it and do the Repair as in: http://www.michaelstevenstech.com/XPrepairinstall.htm 11) you might need to go through a series of re-boots, with a bit of luck, everything should work The procedure above has the advantage that should anything go wrong, your OLD hard disk has got no modifications of any kind, so it will work if put back on the OLD machine, and you can start anew, maybe with a different software/procedure. NEVER, and when I say NEVER, I mean NEVER allow the new machine to boot XP from HD when BOTH hard disks are connected to it. If anything is not clear, do post your perplexities before starting the cloning. A final advice: take your time, possibly during a weekend, tell friends and relatives you are somewhere else, switch off your telephone, if possible have an alternate machine connected to the internet to be able to google your way or ask for help. jaclaz

For PE (Windows XP/2003 based) systems, probably your best bet is Native_ex/PicoXP, Winbuilder projects, here: http://www.boot-land.net/ For "Full XP" it is nlite. For Linux, it is difficult to say, as there so many distributions, my preference lately goes to Debian derivatives, like Knoppix or one of the derivatives from Knoppix, there are large communnities of "Knoppix modders", but I guess that it is just my personal opinion. jaclaz

Yes, problem is, it is not yet clear to me what you want to do. I mean, nlite can help you make a good, up-to-date, slipstreamed, possibly partially unattended INSTALL CD. It will not, in any way help you to TRANSFER your actual system to the new machine. In other words, nlite is "feeded" with Microsoft Windows XP INSTALL files, being them from original CD, from a \I386 directiry on your HD, or from Service Packs and Updates, plus it can integrate Third Party INSTALL files (for example drivers), though quite obviously it is a rather unuseful waste of space on the CD to integrate drivers specific to ONE machine if the intended use of the CD is installing on ANOTHER machine, unless the two are identical. You should get all the drivers for the NEW machine and integrate them in the nlite slipstreamed CD. But again, on the CD built with nlite there will be not the following (currently on the HD): 1) Data 2) Installed applications 3) Settings, including Network names, tcp/ip addresses, 4) Users, Passwords, ACLs, Disk quotas and more generally everything that has or needs to be set or changed after the initial installation of XP (this can be partially covered by using unattended features, but they are a bit tricky, and definitely NOT suggested as a "first try") That is why the idea of imaging has been suggested, though, as said it is not an easy and straightforward task, and needs ANYWAY a good known-to-be-working slipstreamed CD, which nlite can help you make, to be able to perform the Repair. In a nutshell, to try the TRANSFER you will need BOTH: a. A slipstreamed (with nlite or other program) Install CD b. An imaging program If you want to re-INSTALL, you need just point a. above. jaclaz

Yep, the "Thumb Drive" really cracks me up.... I wish I had one of those. jaclaz

With all due respect, 460 Mb appears to me more like "Light Heavyweight" than "VeryLight" (I presume you are talking about the OS, without, say, Office, IE7, Photoshop or whatever big-sized application. Speaking of Win2K, I would put "Extremely light" below 100 Mb, "Very Light" between 100 and 200, "Light" between 200 and 300, "Middleweight" between 300 and 400, "Light Heavyweight" between 400 and 500, and "Heavyweight" for anything bigger. If I recall correctly, an "untouched" install of Win2K is about 600 Mb. jaclaz

@ripken204 If you click on the links on my original post, you might be able to understand the idea behind it. jaclaz

Hmmm, "Usb flash drive" appears to be the most "correct" one, but there are of course exceptions, I guess these: Pen Drive USB key Thumb Drive USB Stick can be called differently with no risk of misunderstandings. jaclaz

Just out of curiosity, what tool did you use to open the plastic case, a sledgehammer? That is very interesting because there is a precedent in a famous Italian trial where the original CD containing the recordings of a supposed case of corruption (all copies proved to have been tampered with, and thus unacceptable as proof by the judge) was said to have been broken by a witness because: Now, a local Radio for about one year made a contest with a prize of something like US$ 5,000.00 for whoever would have been able to break a CD by letting it fall and catching it between his/her legs. The prize was never awarded as noone was ever able to repeat the alleged performance. jaclaz

Hmmm, the "traditional" way to try to avoid the Repair was to change the IDE bus drivers with the default MS ones "Standard Dual Channel PCI IDE Controller", and the Video to "Standard VGA", both of which are however suggested, but since you are going to have a SATA drive, my guess is that a Repair will be necessary anyway. Pardon me, but it is not very clear to me what do you mean by: Can you elaborate on the method you are planning? jaclaz

@ElTorqiro Nice find! Though when Nuhi will have tested and integrated your idea in nlite your program might prove to be mostly unneeded, if I may, I would suggest to NOT "abandon it, but rather enhance it. What if some features are added to it, something like: 1) Backup sfcfiles.dll to sfcfiles%date%%time%.old 2) Make a list of files from current sfcfiles.dll dynamically (i.e. without having an hardcoded set of files linked to a certain version of scfiles.dll) 3) Let the user choose from the list (maybe with a multi-page/multi-selection) which files he wants WFP disabled for 4) have an option to restore a previously backed up sfcfiles%date%%time%.old to sfcfiles.dll This way even the n00b could use the app in a relatively safe manner.... Cheers, jaclaz

hmmm, what ATTRIButes has that file? ATTRIB "%SYSTEMDRIVE%\ProgramData\Microsoft\Windows\Start Menu\Programs\Startup\StartVista.lnk" Maybe is hidden / system ... Besides, del /f /a /q the /a parameters, at least in 2K/XP needs the correct attribute following, like in /a:HSR the /q switch is unneeded the /f forces the deletion of a read only file, but only if it is not hidden As a general "rule of thumb" when writing batches, make them in a manner that they can be run from an open command prompt so that you have visual feedback, add to them as much PAUSE statements as you see fit to parse the output, if needed put some @Echo on and @Echo off just before and after relevant lines, to be able to check if the batch works properly, when using parameters in commands, always try with no parameters or just one at the time, double check sintax and make sure to have understood it before using parameters. A good site with help for the various commands is this one: http://www.ss64.com/nt/ Always check this site: http://www.robvanderwoude.com/ to learn more about sintax and to see examples of well written batches. jaclaz

@buseeliu Good find! It's good to have more eyes checking, typos are so easy to go undetected. See you soon ilko_t, be well. jaclaz

Hmmm, I cannot guarantee they will be "welcome" , but rest assured we will try our best to reply them . 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