jaclaz

Well, you should try using some more modern techniques. The thread by Markymoo: http://www.msfn.org/board/index.php?showtopic=69211 is very old, and grub4dos has changed a lot since, and as well distros. Take your time around here: http://www.boot-land.net/forums/index.php?showforum=66 If you cannot find yourself a suitable solution, post detailing WHAT you wish to achive (as opposed on HOW you want to achieve it ), I am sure you will get all the needed help.... jaclaz

Just for the record, a comparison test with different filesystems on different sticks: http://www.testfreaks.com/blog/information...-ntfs-vs-exfat/ Is it possible that Vista has re-added some speed to FAT32? jaclaz

If you just formatted your hard disk, something worth a try as first thing is TESTDISK: http://www.cgsecurity.org/wiki/TestDisk Be aware that if you re-build your filesystem and it contains a virus, it is possible that you re-trigger it. To recover single files from RAW data, you can try using it's accomapanying app PHOTOREC. jaclaz

You too need some more reading, what you described is almost but not quite, completely UNLIKE the way WinsetupfromUSB works. A rough explanation is the following : Start the app Insert a stick Choose options PROPERLY Run the app Remove the stick This stick, once booted from on any machine, is capable to install XP on it, just like a booted CD would do. Once the XP has finished installing, you can carry the stick to another machine and install XP to it.....and so on. No need whatsoever to apologize, the main thing is that you succeeded in what you wanted to achieve. jaclaz

The 1.6 is XP/2003 as well: http://web.archive.org/web/20030801141307/...ds/download.htm http://web.archive.org/web/20040607134323/...ds/download.htm jaclaz

Yep. But it would be a little limitative, as I see it, being comaptible ONLY with a newly formatted drive and with ONLY one NT/2K/XP/2003 and no multibooting. jaclaz

Did you tried with a "malformed" directory name? Does XP Setup delete the folder anywway? jaclaz

Also, there is a project OfflineSysPrep, here: http://www.911cd.net/forums//index.php?showforum=43 that might be just waht you are looking for. jaclaz

Yep, but still you are failing (and this is surely not under a NDA ) whether you want a tool to be able to calculate exactly an offset (which the spreadsheet might be) or if you want to know a suggested range (for which anything in this thread is pretty much useless). The Server 2003 diskpart.exe has the same (though with another "unit of measure") function of diskpar: http://www.messagingtalk.org/content/69.html http://msexchangeteam.com/archive/2005/08/10/408950.aspx I cannot see any difference between "offset" and "align", unless this one (maybe): http://nathanbean.com/wp/?p=13 This should be the (hopefully complete) diskpart commands explanation, though it is not really clear: http://technet.microsoft.com/en-us/library/cc766465.aspx jaclaz

"Say" port to Win32 (sort of): http://krolik.net/post/Say-exe-a-simple-co...or-Windows.aspx jaclaz

The problem might rely with Service Pack files (you need the SAME SP level as your installed OS), and with updates. All "personal" data and settings should remain untouched. Do read THOROUGHFULLY this (though it is XP related, same should apply to Server 2003): http://www.michaelstevenstech.com/XPrepairinstall.htm In ANY case, do make a full image of the system "as is", just in case. jaclaz

Well, not so easy. I have full faith on the power of grub4dos dd command, but alas not yet enough on grub4dos scripting language. You may have a "strange" BOOT.INI already on the target machine. See the example posted here: http://www.msfn.org/board/How-to-boot-inst...html&st=244 Are you positive that you can find a way (entirely in grub4dos) to detect the position of z, both here: and here: And later read the z value, calculate the z-1 value and write it in both places? jaclaz

Just for fun , and for future memory . The \ (backslash) trick works nicely in 7-zip filemanager too. Now a nice one (directory originally named fd - as acronym for fake directory): C:\testdirtilde>dir Il volume nell'unità C non ha etichetta. Numero di serie del volume: C08C-CFD9 Directory di C:\testdirtilde 16/03/2009 16.25 <DIR> . 16/03/2009 16.25 <DIR> .. 16/03/2009 15.59 <DIR> fd 0 File 0 byte 3 Directory 290.000.093.184 byte disponibili C:\testdirtilde>dir /x Il volume nell'unità C non ha etichetta. Numero di serie del volume: C08C-CFD9 Directory di C:\testdirtilde 16/03/2009 16.25 <DIR> . 16/03/2009 16.25 <DIR> .. 16/03/2009 15.59 <DIR> fd 0 File 0 byte 3 Directory 290.000.093.184 byte disponibili In 7-zip rename fd to ALT+0160..\ (meaning keep pressed ALT key, tap 0160 on numeric keyboard, than a DOT, than another DOT than a BACKSLASH): C:\testdirtilde>dir Il volume nell'unità C non ha etichetta. Numero di serie del volume: C08C-CFD9 Directory di C:\testdirtilde 16/03/2009 16.30 <DIR> . 16/03/2009 16.30 <DIR> .. 16/03/2009 15.59 <DIR> .. 0 File 0 byte 3 Directory 290.000.027.648 byte disponibili C:\testdirtilde>dir /x Il volume nell'unità C non ha etichetta. Numero di serie del volume: C08C-CFD9 Directory di C:\testdirtilde 16/03/2009 16.30 <DIR> . 16/03/2009 16.30 <DIR> .. 16/03/2009 15.59 <DIR> 71E7~1 .. 0 File 0 byte 3 Directory 290.000.027.648 byte disponibili C:\testdirtilde>cd 71e7~1 C:\testdirtilde\71E7~1> Folder is "invalid" in explorer and practically inaccessible from command line too, unless you use "the dir /x name". Works allright in 7-zip, though it is "strange" to see two seemingly "double dot " named directories.... You can do the same with SPACE DOT DOT BACKSLASH, the name will be 71E3~1 And now the nice part: After having renamed a directory to SPACE DOT DOT BACKSLASH, make another one, and rename it to ALT+160 DOT DOT BACKSLASH (same as before), it should get 71E7~1 as before, right? WRONG! This one will get just one DOT: C:\testdirtilde>dir Il volume nell'unità C non ha etichetta. Numero di serie del volume: C08C-CFD9 Directory di C:\testdirtilde 16/03/2009 16.46 <DIR> . 16/03/2009 16.46 <DIR> .. 16/03/2009 15.59 <DIR> .. 16/03/2009 16.46 <DIR> . 0 File 0 byte 4 Directory 289.999.880.192 byte disponibili C:\testdirtilde>dir /x Il volume nell'unità C non ha etichetta. Numero di serie del volume: C08C-CFD9 Directory di C:\testdirtilde 16/03/2009 16.46 <DIR> . 16/03/2009 16.46 <DIR> .. 16/03/2009 15.59 <DIR> 71E3~1 .. 16/03/2009 16.46 <DIR> E20A~1 . 0 File 0 byte 4 Directory 289.999.880.192 byte disponibili and E20A~1 Pretty much unuseful..... but maybe can come handy for something.... B) jaclaz

Sure, as well as the old WINNT.EXE from DOS, but what would be the fun if we don't look and hopefully find new ways? jaclaz

Happy problem is solved. jaclaz

Maybe you were thinking about this one: http://downloads.zdnet.com/abstract.aspx?docid=744749 Homepage is here: http://www.dkpcode.com/html/downloads.html#DKHardDrive-Light Though ZDnet says: Developer says: jaclaz

It seems like a problem with the actual CD booting. Are the DVD's ATA or SATA? If SATA double check BIOS settings: http://www.computing.net/answers/hardware/...rive/51227.html You may also want to try disconnecting (temporarily) one of the two DVD's. jaclaz

I am starting to maybe understand. For the "casual" onlooker, this thread needs to be read together with this one too: http://www.msfn.org/board/index.php?showtopic=130828&hl= Still I have quite a few questions: What is the reason of the "abnormal" directory name? I mean, if you make a "normal" directory named "XPINSTALL" won't it be accessed by it's short name XP~1? Would this work with any filesystem or only on FAT? Can't we use a "fixed 4 character" and "normal" directory? I mean $WIN_NT$.~BT is 12 characters, why cannot we have (say) 1234\56789AB or 1\23456789AB or whatever "in the middle"? As well, once we have decided that we "need" 4 characters for the "base" directory name, can we, as txtsetup.sif is 12 characters as well, 1234\txsetup (with no extension?) or is the .sif extension needed? Same for ntdetect.com that could become 1234\ntdtect Same for bootfont.bin that could become 1234\bootfnt Same for boot.ini that could become 1234\ini What is the reason to change the name of menu.lst to "me"? It is not invoked by any of the NT files.... The above said, why do we need the "further" \I386? I mean, can we have INSTEAD of these: these: I hope to have not flooded you too much with all these questions , just trying to understand how to stretch to the maximum extents the "limits" of this renaming solution.... jaclaz

Well, it won't work. However that's the additional parameter you are giving to mkbtiso.bat, which will result in correspondent mkisofs commands: : *** File system options set fs_options= if "%1" == "-u" set fs_options=-N -d -D -no-iso-translate -relaxed-filenames -J -joliet-long -udf if "%1" == "-j" set fs_options=-N -d -D -no-iso-translate -relaxed-filenames -J -joliet-long if "%1" == "-l" set fs_options=-N -d -D -no-iso-translate -relaxed-filenames -max-iso9660-filenames -allow-multidot -allow-leading-dots -allow-lowercase if "%1" == "-lu" set fs_options=-N -d -D -no-iso-translate -relaxed-filenames -max-iso9660-filenames -allow-multidot -allow-leading-dots if "%1" == "-s" set fs_options=-N -d -D -no-iso-translate -relaxed-filenames if "%1" == "-v2" set fs_options=-iso-level 4 if "%1" == "-v2u" set fs_options=-iso-level 4 -force-uppercase : -N, -omit-version-number Omit version number from ISO9660 filename (violates ISO9660) : -d, -omit-period Omit trailing periods from filenames (violates ISO9660) : -D, -disable-deep-relocation Disable deep directory relocation (violates ISO9660) : -no-iso-translate Do not translate illegal ISO characters '~', '-' and '#' (violates ISO9660) : -relaxed-filenames Allow 7 bit ASCII except lower case characters (violates ISO9660) : -max-iso9660-filenames Allow 37 character filenames for ISO9660 names (violates ISO9660) : -allow-multidot Allow more than one dot in filenames (e.g. .tar.gz) (violates ISO9660) : -L, -allow-leading-dots Allow ISO9660 filenames to start with '.' (violates ISO9660) : -allow-lowercase Allow lower case characters in addition to the current character set (violates ISO9660) : -force-uppercase Do not allow lower case characters Thus, you can try INSTEAD of -j the -v2u one, or as said use directly mkisofs with the command line in the given link. jaclaz

And/or check these: http://www.911cd.net/forums//index.php?showtopic=16381 http://www.911cd.net/forums//index.php?showtopic=19109 Where you may find some ideas/tricks for the opposite thing. And also have a look at this: http://www.pcdecrapifier.com/home (again NOT what you asked for, but something that may be used as reference) jaclaz

You are running mkisofs with some "not appropriate" command line parameters. Please post the command line you are using or try with the one here: http://www.911cd.net/forums//index.php?sho...22726&st=13 You seem like not using "isolevel 4" jaclaz

Not really. As far as you get the RIGHT drive letters in the WINNT32.EXE parameters I cannot see how the running of WINNT32.EXE may affect the running system. But of course having a backup is always recommended. I was thinking, that although it might be really SLOW, you could setup in your Vista PC a Qemu VM, and then use the \\PHYSICALDRIVEn connection: http://www.msfn.org/board/Adding-QEMU-func...sb-t112746.html booting the VM from a PE CD of some kind and running the WINNT32.EXE to install the XP on the external drive. Or possibly, with the above setup, you should be able to use this method: http://www.msfn.org/board/index.php?showtopic=121446 jaclaz

Sorry I did not explain myself, or possibly haven't understood fully your report. If I get it right, this: This results in a directory XPLS containing the previous contents of the $WIN_NT$.~BT one plus the two files migrate.inf and winnt.sif. Than the contents of $WIN_NT$.~LS are moved to \XPLS ( or \XPLS\I386)? Can you simply attach a DIR /S of your modified stick, so that I can fully understand the directory structure and which files are where? I was presuming that your tests are made with the (right or wrong ) idea of putting the whole structure under a single directory (\XPLS) as to not "clutter" the ROOT of the stick/HD partition. What I am trying to understand is if we can somehow (through a batch for example) create a single directory (like \XPLS) instead of two (\XPLS and \XPLS\I386) and whether we can copy files to it/them directly from the \I386 directory of source CD. Or am I alltogether missing the point? Not really. rdummy.sys is to make a HD seen as "Removable" as opposed to "Fixed" once the GUI is up and running. During initial text mode part of setup, first active partition on first hard disk (read booted USB device) will get C:\ unless a migrate.inf (or some other unknown trick) is used, this will happen long before rdummy.sys gets "into play". jaclaz

I may add that however, grub4dos dd should be able to change a single byte even on a NTFS filesystem with no problems, haven't tested it, but from the grub4dos readme: should mean that it is possible that a problem happens, not necessarily that it will happen. The difficult part would be to tell it WHICH byte to change, i.e. somehow scripting the feature, both finding the "address" that needs to be changed and the right "value" to write. The "z-1" concept was devised to work on "ANY" setup : http://www.msfn.org/board/How-to-boot-inst...html&st=240 and following. jaclaz

Very interesting. This should mean that we could (instead of using \XPLS\I386) using directly \I386, and thus just by changing two files be able to copy the \I386 folder from Cd, right? The migrate.inf, as far as I can say, will be needed anyway (or it must be replaced with "something else"), it's the only way to prevent the USB stick (or Hard Disk) from becoming "C:\" in the install. I am not sure to have understood your report on the linked thread. Could you try expanding on it? jaclaz