ilko_t

Nice catch, I should have included it... edit: I've uploaded a new version, link is in the first post.

@class101 Can you try renaming WinSetupFromUSB directory to something simple, like WinSetup for example. Ignore the message about migrate.inf missing, fixed/removable type does not matter as well, rdummy is not used at all and the radio buttons do nothing now, they are to be removed in the final release. If you want to use migrate.inf manually copy it from the ISO to the AMD64 folder on the USB disk.

You mentioned that it's compiling in 64 bit env., I must have missed a compiled exe if you posted such. The other reason is that prefer BTS version, one thing less to worry about, renaming setup.exe and launching it. Wasn't that happening with fixed type media and when mapping was not performed? I think this has something to do with Windows detecting the boot device and something strange around it, so it doesn't give it drive letter, or something along those lines. Remember, USB sticks work just fine with 64 bit versions. Hmm, in my tests with hard disk and 64 bit vers. %CDDRIVE% did not get value, tag file was not found in presetup.cmd. USB disk partition did not have any drive letter assigned when fake setup.exe was launched. Did you test with 64 bit and USB hard disk? I'd try that, want to get away for a bit from this matter, had too much testing last weeks and need to clear up my head a bit Nope. Does harddisk1 represent ARC path to disk(1), or it's internal numeration, as drivers return it?Next week if time allows will go and get the cheapest CPU, supporting virtualization, so I can test 64 bit versions in VMWare. Good excuse for a little upgrade On real hardware this takes way too much time.

You are correct, it's the opposite of what I posted, editing the post above.I'd recommend you to stick with the test version of WinSetupFromUSB, most of the changes were coded directly and I am posting the procedure here by actually reading the AutoIt code and looking at already made USB disk.

There is a new approach, much easier and without most of the limitations until now:http://www.msfn.org/board/install-2000-xp-...so-t139737.html There is a test version of WinSetupFromUSB attached, don't pay attention to BOOT.INI, FIXED/REMOVABLE and STARTUP FILES ONLY fields, they do nothing and will be removed in next release. Should work just fine with USB stick and x64 sources. Second boot, for GUI mode, can be either the USB stick or the internal hard disk.

Exactly as you figured it out. fixsrcpath.exe=1,,,,,,,82,0,0 presetup.cmd=1,,,,,,,82,0,0 setupORG.exe=1,,,,,,,82,0,0Section is still SourceDisksFiles. Those files are in AMD64 folder in source. And yes, sorry for confusion, fake setup.exe is taken from BTS DP, auto renames original setup.exe and launches it. SysWOW redirection was real pain in the rear to figure out, I was trying with batch files, but it was behaving very weird and inconsistent, even using start64.exe to launch 64 bit cmd.exe and execute the batch file. Next was to compile 64 bit version of the fake setup.exe, but rather than that, I just created AutoIt script, which works on both platforms, disabling SysWow redirection, it was much quicker and safer to do it this way. I hope I am not forgetting something, I was coding all changes directly in the AutoIt script, but the basics are covered above. As for the USB start type changes- I was thinking in this direction too, what stopped me was why 2003 SP1 32 bit works just fine, but 64 bit version not, in the very same setup , the USB stick works fine. Did MS introduced more changes compared to 32 bit similar versions? The other thing is that looking at setuplog.txt reveals that the USB disk is enumerated, I suspected other reason for this behavior. As for the drive letters- when using grub4dos MBR there is no need of active partition, so partitions on the USB disk will get lower priority in drive letter assignment. Another idea- hide the partitions for the Text mode, unhide them for GUI, not tested, should work, risky though for regular user. The idea with editing TXTSETUP in RAM is great, didn't know it's already implemented in grub4dos, thanks.

presetup.cmd: @echo off SET TAGFILE=\WIN_SETUP FOR %%h IN (U D M N O P Q R S T V W X Y) DO IF EXIST "%%h:%TAGFILE%" SET USBDRIVE=%%h: if "%USBDRIVE%" == "" ( FOR %%h IN (C E F G H I J K L) DO IF EXIST "%%h:%TAGFILE%" SET USBDRIVE=%%h: ) set srcpath=\??\%USBDRIVE%\WIN_SETUP\2003\ %systemroot%\system32\fixsrcpath.exe %srcpath% EXIT fixsrcpath.exe is a simple AutoIt code- attached with the compiled fixsrcpath.exe, along with the fake setup.ex_. Works for both 32 and 64 bits versions of setup. Added entries to TXTSETUP.SIF in the ISO: ... [SourceDisksFiles] ... fixsrcpath.exe=1,,,,,,,2,0,0 presetup.cmd=1,,,,,,,2,0,0 setupORG.exe=1,,,,,,,2,0,0 ... [SetupData] SetupSourcePath ="\WIN_SETUP\2003\" SetupSourceDevice=\ArcName\multi(0)disk(0)rdisk(1)partition(1) BootPath="\WIN_SETUP\2003\I386\" BootDevice="multi(0)disk(0)rdisk(1)partition(1)" ... Make sure you use similar entries for grub4dos menu.lst as posted above. Extract the existing original setup.ex_ and rename to setupORG.exe in \I386\. Put setup.ex_ from the archive in \I386\. As for your idea- should be easily doable- just slightly different txtsetup.sif's in the ISO, pointing to the same source, which has needed files for all versions mentioned. I'd need to get back to your notes for details. fixsrcpath.7z

Yep, even more: http://www.msfn.org/board/install-2000-xp-...so-t139737.html

There are a few entries in txtsetup.sif, allowing Setup to continue loading driver files for the first stage, until the partitioning screen, from alternative location, this is our USB stick/disk. Location of the rest of the files, needed to continue Text mode (EULA and file copy part) are given as per this topic: http://www.msfn.org/board/2-t119742.html 1. Create a small ISO containing only \I386\SETUPLDR.BIN, \I386\NTDETECT.COM and \I386\TXTSETUP.SIF for 32-bit setups. In case of 64-bit only TXTSETUP.SIF is in I386 AMD64, the other 2 files are in \AMD64\ I386. 2. Add these lines to your TXTSETUP.SIF in the ISO: [SetupData] .... SetupSourcePath ="\WIN_SETUP\2000\" SetupSourceDevice=\ArcName\multi(0)disk(0)rdisk(1)partition(1) BootPath="\WIN_SETUP\2000\I386\" BootDevice="multi(0)disk(0)rdisk(1)partition(1)" ....After loading the 3 files from the ISO setup continues loading the other from BootDevice\BootPath. 3. Grub4Dos menu.lst: title First part of 2000 setup find --set-root /WIN_SETUP/2000.ISO map --mem /WIN_SETUP/2000.ISO (0xff) savedefault 1 map (hd0) (hd1) map (hd1) (hd0) map --hook root (0xff) chainloader /I386/SETUPLDR.BIN title Second part of 2000 setup/Start from the first internal disk savedefault map (hd0) (hd1) map (hd1) (hd0) map --hook rootnoverify (hd0) chainloader (hd0)+1 4. Put that ISO say in \WIN_SETUP\ on the USB disk. 5. Copy the all 2000 setup files in \WIN_SETUP\2000\ 6. At start of GUI mode the value of sourcepath in $winnt$.inf is "translated" to dos path, with a drive letter and is used for the rest of the GUI mode. Default behavior is to translate this NT path to Dos path, which is used for the GUI mode. If the value is ARC path it gets translated to \device\harddiskX\partitionY\WIN_SETUP\2000\. If the value is \device\harddiskX\PartitionY\WIN_SETUP\2000\ it gets translated to U:\WIN_SETUP\2000\. This is saved as the value of dospath entry in $winnt$.inf. Instead, use presetup.cmd and Pyron's fake setup to change 'setupsource' value to something more useful- "\??\U:\WIN_SETUP\" U: is taken by searching in all local drives for a tag file. Winnt.sif if present in the source folder (\WIN_SETUP\2000\I386\) is applied, migrate.inf too. The ISO file needs just the 3 files mentioned. If txtsetup.oem is present in the ISO, alongside txtsetup.sif, it's also honored. No files are deleted from the source folder. Msdosinitiated in sould be 0, NO, or absent in winnt.sif, as in a regular source. Boot.ini is generated correctly and placed always on the internal disk. Practically unlimited number of sources can be easily placed on the USB disk. Tested successfully with USB stick on all possible Windows versions 2000-XP-2003, on virtual machines and real hardware. The only problems I got were with USB hard disk and 64-bit versions, this could be because of the IDEtoUSB adapter I am using. At start of GUI mode partitions on USB disk do not get drive letters. Diskpart shows the disk, but no volumes are mounted from it, just the internal disk To do list: Find out what's going on with USB hard disks and x64 versions. Test USB stick/disk mapped to say hd21. Find workaround for USB sticks, seen as floppy by BIOS. Lacking hardware for this part. Here is a very unfinished, test version of WinSetupFromUSB, which has a lot to be changed and fixed, but does the most of the required changes, if anyone want's to jump in and help testing: http://www.datafilehost.com/download-48372825.html Same approach might be used for loading multiple BartPEs in the USB stick/disk, no need of the ISO file, just settings in txtsetup.sif pointing where the files are to be found, not tested. edit: (18-11-2009) Fixed locations of files in case of 64 bit versions edit: (20-11-2009) WinSetupFromUSB download link modified edit: (21-11-2009) WinSetupFromUSB download link modified edit: (10-12-2009) WinSetupFromUSB download link modified edit: (19-12-2009) WinSetupFromUSB download link modified

Say string="abs" 1. Uppercase it 2. Put the ASCII code for each symbol in an array 3. For each element in the array calculate $iHash = 37 * $iHash + $Array[$i] 4. Output is the hexadecimal value of the modal of the positive(abs) result of (314159269 * $iHash) divided by 1000000007. Apparently in the above calculations C value types uint and int should be used to store results in, or values get different presentation. Still can't quite figure out this part, despite all the reading the last couple of days.

Thanks for sharing this, it definitely will help many

Not sure which one you have in mind, but is it the attachmen t in post #97? http://www.msfn.org/board/solved-usbstick-...p;view=findpost http://www.msfn.org/board/index.php?act=at...st&id=26992 And BTW- not only theoretically capable, practically as well

Your stick is presented by BIOS as a floppy. Try to find an option in BIOS for USB emulation type: http://www.msfn.org/board/problem-usbkey-i...on-t139446.html

Is menu.lst in root of the USB stick? Are those 3 files in D:\$WIN_NT$.~LS\I386\ ? Try in grub4dos command line to type: cat (fd0)/menu.lst cat (fd1)/menu.lst cat (hd0,0)/menu.lst Does any of them find and print menu.lst? Which one? FD0?

You've got a lovely knowledgeable crystal ball, I have no doubts

It's the same prefix for the same stick when Realtek driver is used, or not. Stick2 and Stick8 are NOT supposed to have same prefix, but Stick2was supposed to have the same prefix with and without Realtek driver, as it happens. Same for Stick8- its ParentIDPrefix does NOT change when Realtek drivers are used. Hope it's clearer for you now, just in case again- no matter that both sticks are the same brand, they are different, and supposedly have different discription, hence different ParentIDprefix, derived from it.

Thanks, this was nice summary.So both USB sticks did NOT change ParentID when Realtek driver was used. As cdob mentioned already- Windows assigns drive letter to the card reader's slots, not to the inserted sd/whatever card. ParentID is a hash of the same string in case of card reader, it does NOT come from the plugged in SD card, but from the reader itself. Whereas these different USB sticks, although from the same manifacturer do have different discriptions, hence the different parentIDs generated from them.

To start the second phase (GUI mode) from the same drive, you'd need to "swap" hard drives order using grub4dos: title Start GUI mode map (hd0) (hd1) map (hd1) (hd0) map --hook find --set-root /ntldr chainloader /ntldr Or boot MBR on HD0 (hd0 after mapping/swapping) directly, not chainloading ntldr: title Start GUI mode map (hd0) (hd1) map (hd1) (hd0) map --hook rootnoverify (hd0) chainloader +1 NTLDR expects NTDETECT.COM in the active partition of the first disk, not on the second, as would be if no swapping is made, hence the need of swapping. I tried this as you said and the install works perfectly. What can I do to slipstream IE7 without generating missing file errors in text setup? Can you help me understand why these errors exist with the RAM loaded version and not when mounted as a CD? There are several reports that nLited sources do NOT work well when booted not from a CD, search this board with few of the file names reported as missing, here is one hit:http://www.msfn.org/board/integration-ie7-...icardie.dll.mui http://www.msfn.org/board/error-winxp-winn...;hl=icardie.dll Here were several similar reports, somewhere in the last pages: http://www.msfn.org/board/32-t120444.html No idea why RAM loaded ISO would differ from a regular CD, seems Setup is picky when detecting source media used and makes additional checks, or the double dotted files matter, or the long file names... Can you attach \I386\layout.inf as well, from the modified source?

Please post/compress&attach \I386\txtsetip.sif and the grub4dos' menu.lst used. Do you have the SP tag files in root of the CD/ISO?

I'd guess sticks seen as removable are displayed the same way as in XP/2003- only one partition can be used. To go around that- either flip the removable bit and use separate partitions as described, or put the other sources in their own folders, initiating setup by entering recovery mode using the one in root-->command prompt and manually executing setup.exe for the desired version. Haven't played much yet with Vista/7...

Here is a bit more information: http://bbs.driverdevelop.com/read.php?tid=96099 http://translate.google.com/translate?hl=e...GGGL_en___GB229 Here is good explanation of the device tree: http://msdn.microsoft.com/en-us/library/aa489660.aspx Osronline have a nice program DevTree, which can display tree from PNP manager perspective, free registration is required for download link: http://www.osronline.com/article.cfm?article=97 About the algorithm calculating the hash- in AutoIt forum helped with it and provided similar code to calculate it in AutoIt, now I can understand the C macro used to calculate it: http://www.autoitscript.com/forum/index.php?showtopic=104426 Can you figure out why exactly the level changes in some occasions? Which one is the missing "hop"? How an internal card reader for example would move one hop up, getting level 6 for example?

It's interesting to follow: Card reader/SD card: Generic windows driver: USB\VID_0BDA&PID_0159\20071114173400000 Name: USB Mass Storage Device Driver installed from d:\windows\inf\usbstor.inf [USBSTOR_BULK]. 1 file(s) used by driver: D:\WINDOWS\system32\drivers\USBSTOR.SYS USBSTOR\DISK&VEN_GENERIC-&PROD_MULTI-CARD&REV_1.00\20071114173400000&0 Name: Generic- Multi-Card USB Device Driver installed from d:\windows\inf\disk.inf [disk_install]. 1 file(s) used by driver: D:\WINDOWS\system32\DRIVERS\disk.sys USBSTOR\DISK&VEN_GENERIC-&PROD_MULTI-CARD&REV_1.00\20071114173400000&0 has hash/parentID "24e8d74f". ================================= Realtek driver: USB\VID_0BDA&PID_0159\20071114173400000 Name: Realtek Card Reader(0159) Driver installed from c:\windows\inf\oem10.inf [RSUSBSTOR]. 3 file(s) used by driver: C:\WINDOWS\System32\Drivers\RTS5121.sys C:\WINDOWS\system32\rts5121.dll C:\WINDOWS\system32\rts5121icon.dll USBSTOR\DISK&VEN_GENERIC-&PROD_MULTI-CARD&REV_1.00\00000 Name: Generic- Multi-Card USB Device Driver installed from c:\windows\inf\disk.inf [disk_install]. 1 file(s) used by driver: C:\WINDOWS\system32\DRIVERS\disk.sys USBSTOR\DISK&VEN_GENERIC-&PROD_MULTI-CARD&REV_1.00\00000results in d7f206a hash. I am rather confused to follow Kingston USB stick "transformations" with all the information scattered around the thread: It this the same stick plugged? USB\VID_0951&PID_1623\00137297175CF971862F0A39 Name: USB Mass Storage Device Driver installed from d:\windows\inf\usbstor.inf [USBSTOR_BULK]. 1 file(s) used by driver: D:\WINDOWS\system32\drivers\USBSTOR.SYS ........... ........... USBSTOR\DISK&VEN_KINGSTON&PROD_DATATRAVELER_120&REV_1.00\00137297175CF971862F0A39&0 Name: Kingston DataTraveler 120 USB Device Driver installed from d:\windows\inf\disk.inf [disk_install]. 1 file(s) used by driver: D:\WINDOWS\system32\DRIVERS\disk.sysThis is hash 15c42460 USB\VID_0951&PID_1607\5B82050053DD Name: USB Mass Storage Device Driver installed from c:\windows\inf\usbstor.inf [USBSTOR_BULK]. 1 file(s) used by driver: C:\WINDOWS\system32\drivers\USBSTOR.SYS ............. ............. USBSTOR\DISK&VEN_KINGSTON&PROD_DATATRAVELER_2.0&REV_PMAP\5B82050053DD&0 Name: Kingston DataTraveler 2.0 USB Device Driver installed from c:\windows\inf\disk.inf [disk_install]. 1 file(s) used by driver: C:\WINDOWS\system32\DRIVERS\disk.sysThis is hash 2ba01341 @robekiaTo follow troubles with 8GB Kingston USB stick can you show me where is the output from devcon and usb_history for the following cases 1) Realtek card reader driver installed and used 2) Generic XP driver used Need 2 pairs of those files, for the two cases above.

One of the many possible ways: 1) Extract contents of the new Firadisk somewhere 2) Install ImDisk: http://www.ltr-data.se/opencode.html#ImDisk 3) Right click on XB_INST.IMA and select "Mount as ImDisk virtual disk", do NOT select read-only on the next screen, say you use drive letter X: 4) Rename existing firadisk.sys to firadisk.sys.old in X:\firadisk\ 5) Copy the new firadisk.sys to X:\firadisk\. You may have to rename firadisk32.sys to firadisk.sys if file names do not match. 6) Right click on X: in explorer and select "Unmount ImDisk virtual disk" or go to control panel-->ImDisk and unmount it from its control panel. Simple?

As for the blank screen- try the newer version of Firadisk. It helped in one case with similarly freezing screen when using 2003 source: http://www.boot-land.net/forums/index.php?...ost&p=83680

It appears the mini emulates your USB stick as a floppy disk, rather than a hard disk. We need it as hard disk. It could be the small 512MB size turning this behavior in BIOS, hence the request to try with larger USB stick. Not that the stick itself is faulty.