ilko_t

Please test the attached version. Extract the file in WinSetupFromUSB folder and launch it. http://www.datafilehost.com/download-2c3b0317.html Yep, the problem must be there, I haven't seen quotes in that section of DOSNET.INF, and included removal if present anyway.

Thanks Wimb, I should have seen that, guess jet lag is killing me more than I realize. It's an AutoIt issue with x64 or Vista, under XP i386 using DVD/CD as source does not fail in that part, I took care of that while coding. Just tested it again under XP with Windows files in CD: ... 2008/08/06 01:27:39- DOSNET.INF parsed, 125 files for ~BT folder 2008/08/06 01:27:39- D:\I386\disk1---> C:\WinSetupFromUSB\TEMP\$WIN_NT$.~BT\disk101 2008/08/06 01:27:39- D:\I386\ntdetect.com---> C:\WinSetupFromUSB\TEMP\$WIN_NT$.~BT\ 2008/08/06 01:27:40- D:\I386\ntkrnlmp.ex_ ---> C:\WinSetupFromUSB\TEMP\$WIN_NT$.~BT\ 2008/08/06 01:27:40- D:\I386\setupldr.bin---> C:\WinSetupFromUSB\TEMP\$WIN_NT$.~BT\ 2008/08/06 01:27:40- D:\I386\txtsetup.sif---> C:\WinSetupFromUSB\TEMP\$WIN_NT$.~BT\ 2008/08/06 01:27:40- D:\I386\biosinfo.inf---> C:\WinSetupFromUSB\TEMP\$WIN_NT$.~BT\ 2008/08/06 01:27:40- D:\I386\disk1---> C:\WinSetupFromUSB\TEMP\$WIN_NT$.~BT\disk102 2008/08/06 01:27:40- D:\I386\hal.dl_ ---> C:\WinSetupFromUSB\TEMP\$WIN_NT$.~BT\ 2008/08/06 01:27:40- D:\I386\halacpi.dl_ ---> C:\WinSetupFromUSB\TEMP\$WIN_NT$.~BT\ 2008/08/06 01:27:40- D:\I386\halapic.dl_ ---> C:\WinSetupFromUSB\TEMP\$WIN_NT$.~BT\ 2008/08/06 01:27:41- D:\I386\halaacpi.dl_ ---> C:\WinSetupFromUSB\TEMP\$WIN_NT$.~BT\ 2008/08/06 01:27:41- D:\I386\drvmain.sdb---> C:\WinSetupFromUSB\TEMP\$WIN_NT$.~BT\ 2008/08/06 01:27:41- D:\I386\setupreg.hiv---> C:\WinSetupFromUSB\TEMP\$WIN_NT$.~BT\ ....At the same time I tested a while ago the program under XP x64 with source on the hard disk and that worked fine. Quites are not needed in AutoIt for file paths and are not added in the script anywhere, I am curious where they came from. May have to compile separate version for x64 when I get back home, will investigate further. Thanks for the accurate reports Raboo, it's pleasure responding to such.

Glad it's solved

For some reason program fails to create the folder and copy from D:\Private\Projekt\USB\WinSetupFromUSB\TEMP\ where ~BT files are placed temporarily. What windows are you using? Do you have rights to write in this folder? Are you using limited account? Is the folder TEMP created and only copy to it fails? Can you try to install the program in let's say D:\WinSetupFromUSB and see if the long path is the problem? To save time and write cycles to the USB stick you may use COPY BOOT FILES ONLY option and eventually QEMU option to test until the problem is fixed.

That's the tricky part Text mode setup is very poorly documented, on purpose or not. Most of the information is gained by experimenting. Same dates back from the times of NT, with slight modifications, patches etc. etc. and has never been aware of USB devices of course. It sometimes fails even in mixed IDE/SATA environment, when even though SATA is set as first BIOS boot device, Text mode setup would place boot files (BOOT.INI/NTLDR/NTDETECT.COM) on the IDE disk, what to say for USB... The logic behind this- it's my guess- IDE disks are fixed. SATA/SCSI/USB disks are considered removable with a little exceptions for SATA working in IDE compatible mode, and USB hard disks, which are seen as fixed disks too. USB sticks generally are recognized as removable, with exceptions again- there is removable bit, which returns device type. Look here for some details: http://www.codeproject.com/KB/system/sovie...;select=1468013 Once Setup determines the available hard disks, it will make the safest bet to ensure next stage can be completed and windows started properly- will place the boot files on the FIRST available FIXED disk/first active primary partition formated in file system, which Windows recognizes. If only removable disks are present, then order is SATA, then USB disks. If you boot from USB stick, and there are present SATA and IDE disk, then order how drives are enumerated and consequently used as preferred boot drive changes- first becomes USB stick. Disabling the IDE channel or removing the IDE device will make SATA disk first disk and boot files will go there. Tricky, isn't it Linux and other OSes will give you options, some user knowledge is expected. MS tries to decide for you, this always has downsides. Now the game joins the factor whether the disk is partitioned according to Text setup rules or not. If it's not, or you choose to format/partition it during Text mode, setup may place the boot files on the already seen as safe partition- on the USB stick what probably was your case your case. It's also picky if there is a hidden partition, which if first- will give C to the USB stick and place boot files there, and give D to the first unhidden primary partition on the hard disk. The way I do it, is to use GParted for example and prepare all partitions in advance, then launch Setup and watch what drive letter gets the internal disk/first active primary part.- if it's C then it's safe to continue. That's the reason I included it as option in WinSetupFromUSB. Mind you that way of setting up Windows is a workaround and little cheating, which became working solution with some downsides, the initial MS way is Windows to be installed in the same disk/partition, where folders ~BT and ~LS are. The proper MS method would be to start PE (preinstall environment) and launch Setup from there, this will place all needed files on the target hard disk, on reboot and starting from it Text mode Setup would begin from there. Mind you winnt32.exe fails in many cases to replicate setup from CD. For example it reads DOSNET.INF to know what to copy, and if you added something extra, which was not reflected in DOSNET.INF, as most integrators do, it will not be copied. Using winnt32.exe and customized OEM disks may give you hard times too. Wimb has started work on this already, another problem is that building PE environment, especially with SDI/RAM boot could be hard for novices even with programs such as BartPE or WinBuilder, and you also need to have all mass storage drivers integrated in that PE too. This adds an extra source for possible problems. Instead of using winnt32, which x64 version won't start on I386 PE and vise versa, it's behaviour is copied- creating ~BT and ~LS folders and placing boot files in root. Hope that gives you and others interested brief idea of the picture.

Can you attach your log file: as well as screenshot of contents or result of dir X: of USB stick root directory, and contents of menu.lst again in USB root. Did you run the program multiple times or everything was done in one go?

IMEPADEN.HLP is in LANG folder. Either copy LANG folder to ~LS\I386\ or rebuild the USB stick changing this option to YES. X) Copy LANG / WIN98X [NO]

I doubt Hitachi microdrive did ANY changes to your MBR/bootsector etc. It only hooks on the fly the query "are you removable or fixed(basic) disk?" when USB disk is inserted, and returns always "fixed". For the technical details look here, it's the same approach: http://www.codeproject.com/KB/system/sovie...;select=1468013 Once you have USB stick seen as fixed, partition operations are allowed. This is done by the OS/Partition program, and Hitachi driver has nothing to do with the read and write operations to the USB stick, neither would rewrite MBR/bootsector ANYWHERE. Since you removed Hitachi microdrive driver from the game, it should not play any role as well. Some BIOS-es have hard time reading beyond certain boundary at boot time and boot loaders may have problems reading the next files- when copying files to USB stick always copy the boot files first. Those are BOOTMGR and BOOT folder for Vista, NTLDR/NTDETECT.COM/BOOT.INI for XP, GRLDR for grub4dos etc. and copy the rest afterwards. Other idea- BOOTMGR doesn't like partitioned USB stick- try newer/older version of the same. Try the same source on the same unpartitioned USB stick to isolate the problem. Try installing grub4dos in MBR or bootsector (guide), and chainload BOOTMGR, assuming VistaPE is in first partition: menu.lst title Start VistaPE root (hd0,0) chainloader /bootmgr If still no luck- use the solution by KTP, it's somehow universal. BTW is this the right subforum?

There is not much we do to migrate.inf, we use it to: 1) make the USB disk write-protected during Text mode Setup, works for XP SP2 only, possibly for SP3 too. and optionally- 2) to preassign drive letter to the USB disk If Setup fails with those errors when you preassign drive letter and gives letter C to your USB disk when letter is not preassigned, then look the problem in the USB disk itself, in particular this 'dual' mode CD/HD. There was a possibility that USB stick was seen as FIXED disk, but you ruled it out. So yes- using another, simple stick or removing U3 from yours should help.

Now it's way clearer, thanks. Try to rebuild the USB stick and change USB disk type to HARD DISK. What letters each drive got? USB stick should be D. If it is then continue Setup and tell results. If it is C again, then you might have to try with another USB stick, unless something else comes up.

Hi, Apart from copying the missing driver to ~BT folder you need to add a few lines to TXTSETUP.SIF in root, or the driver will NOT be used. Did you do that? There are other options to supply the missing driver: 1) F6 and floppy disk 2) grub4dos and floppy image of the disk with drivers 3) Integrating it to your source with tools like nLite 4) Slipstreaming BTS mass storage drivers pack And a few other methods which are a bit more complicated to mention. Try first this. I guess without the proper driver being used you installed Windows on your USB stick, hence the error about HAL.DLL. Are you sure that your HARD DISK was displayed when you got past Text Mode? What drive letter each hard disk and USB stick got?

@jaclaz Thanks, that's very good idea. Using tag file could be tricky- I can't think of any file in root, which gets renamed or deleted after install is completed. If it's in a folder, then may be yes, but what about people changing their windows or program files folders... May this is a solution, even though we are getting into too many submenus: menu.lst: title Windows Install configfile /windows.lst savedefault windows.lst: default /windefault title Text mode Windows XP chainloader .... savedafault 1 title GUI mode Windows XP chainloader /ntldr savedefault title Text mode Windows 2003 chainloader .... savedafault 1 title GUI mode Windows 2003 chainloader /ntldr savedefault All Text mode entries will make default the second entry, even though it's name is for XP, but it loads the same NTLDR/BOOT.INI. Then the second entry will open BOOT.INI entries, which makes one more menu. I will try to put all that and see how it feels when using it.

When saying 'unattended' what do you exactly mean?

Hope you like it It is considerably faster, especially when using fast USB stick or hard disk and your BIOS supports USB boot in full 2.0 speed. In some cases NTFS is reported to perform times faster than FAT16/32, I guess this happens when Text mode setup tries to delete files from the write-protected USB disk and have no further explanation why exactly. Keep in mind that not all BIOSes support boot from NTFS formatted USB disks, and NTFS on USB stick may 'wear it' sooner, depending on it's quality and usage.

The thing is once Text mode is selected in menu.lst, on next launch of grub4dos the second part(GUI) to be default, and eventually fully unattended installation performed.Menu.lst is created dynamically and entries are added to an existing one, which if not present is created. On first run of the program one may not choose to add Windows source. Thus the entries number 0-3 for example will be occupied by Bart PE, Vista setup etc. Next run- add windows source. This will add the pair as entry #4 and 5: title First part (Text mode) of $version setup chainloader /$win_nt$.~bt/setupldr.bin savedefault fallback title Second part (GUI mode) of $version setup root... chainloader /ntldr In order to set fallback entry AND set it default I need to know that last entry, for the GUI mode what number in menu.lst is. Why. What came in my head so far is to separate the entries by seeking for 'title', so everything between two 'title' is an entry. Then look in this entry if string 'ntldr' is present, ignoring the commented lines, and count what number it is. Then set this number as a fallback. The problem is when a new Windows source is added to the USB disk. This will add another pair of entries. The first entry will deffer as setupldr.bin will be in another folder, but the second entry will differ against the similar one only in it's title, where $version is used. Creation of second entry (GUI mode) could be omitted, using one for all Windows sources, not adding for which version of Windows it is as that's only for guidance. But in this case menu.lst may end up like: I wanted to avoid that, as if one wants to install say Windows 2000, he'd expect second part to be below the first part, which is why I add them in pairs: Now if first variant is better- with only one entry for the GUI mode, then will have to seek in menu.lst if 'Second part(GUI Mode) of Windows Setup + Start it for a first time' is present, and if not- add a new one. If the second variant, with pairs, is better, then it's tricky, which entry should be set as fallback entry? Another variant as I am thinking more on this- no need to use 'savedefault fallback', but rather 'savedefault X' and still use pairs. When adding new entries the program will count what number(Y) in menu.lst "First part(Text Mode) of Windows 2000 standard" is, and set "savedefault X+1". All the variants assume that entries above those lines are not deleted, or everything will get messed up. Thinking of that, wouldn't be easier and safer just to include in the ReadMe brief information how to be set up manually? So one will be aware what to change if wants GUI mode to be selected automatically, and if decides to delete entries. I am puzzled What do you guys think?

@Wimb- I'll try to explain in details the way I see all this. The project started as alternative method of installing Windows from USB. The known ones are winnt from DOS and winnt32 or it's variants as PE plugins, started from PE environment. As such alternative, it was rather interesting from experimenting and inventing point of view, rather than a practical sollution. It turned out to be practical since Asus EeePC appeared and the interest boomed. Why- most of these users had no idea what BartPE or winnt32.exe is, neither what unattended install or winnt.sif is. Not to mention building BartPE, integrating mass storage drivers etc. They just needed one-off installation of their Windows source, whatever it is (slimmed down, unattended, with extra programs/addons...), from USB, with a few mouse clicks or a few answers, in the way they are used to- as if it was started from CD. As this alternative method got polished/sophisticated and popularity increased, more and more experienced users became interested. And you have done A LOT for this to happen. Following these thoughts I assume there are 2 types of 'potential users': 1) Who know what unattended (and slimming down or adding drivers/programs) Windows source is, and presumably know at least one of the popular methods to perform that: http://www.nliteos.com/ http://winfuture.de/xpisobuilder3_en XPPRO_CD\SUPPORT\TOOLS\DEPLOY.CAB\SetupMGR.exe XPPRO_CD\SUPPORT\TOOLS\DEPLOY.CAB\ref.chm + Notepad.exe-->winnt.sif http://unattended.msfn.org/unattended.xp/ + Notepad.exe-->winnt.sif www.google.com --> 'unattended windows setup' 2) Ones who have no clue what the above is, and want install from USB with a few mouse clicks, without being bothered with extra information or questions. In case of 1)- Is there a point providing this functionality, overlapping famous and well documented/supported tools? In case of 2)- Is it the time to go into that curve? Is he interested at all in these options or simply wants to install his Windows the way he knows? Even if he is interested, I'd prefer to include the information in a ReadMe file and point to the right direction(above), rather than implementing this functionality in the program itself, overloading the main interface with checkboxes or messages. Simple displaying winnt.sif entries I find useless for novices, as those entries also have to be explained what they mean with their alternative values. Once he knows how many things could be done to his source, the problematic 8 entries will not be the only ones wanted. Same applies for LANG folder or CMPNENTS for MCE or Tablet, which absence could lead to fatal errors during or after installation, if one had already enough new information and on the next message chooses randomly yes/no, without reading a word. Believe me, this is what happens most of the time. If the point to display winnt.sif is to use as reminder to the experienced user what is going to be used, I may add a button or message box "Do you want to display winnt.sif" and launch "notepad.exe winnt.sif". Contrary- we have there important entries, curious people according to practice and Murphy's law tend to mess exactly where they are not supposed to. Keeping out of focus winnt.sif, which performs the most important steps to be USB setup successful, is preferred. As time goes by, a tab "advanced settings" could be added. For now I don't have the willingness and the spare time to do that, my mind simply refuses to think about concentrating on this subject. I'd rather spend more time on simplifying and automating install from PE environment, finding a way to protect files during Text mode in 2000/2003 versions, or making x64 version of rdummy.sys, than implement features, which are already well covered by other means. Don't forget that XP/2003 days are going to an end as well. Within a few years all this will be buried. In addition- the program is run from normal Windows environment, and your toolbox(Internet, Notepad, Help files, NLite...) is full. If it was in PE environment, where tools are limited, then yes, it could be good option. Another point, which is rather personal- I am an old schooler, prefer simplicity, small sizes and information thrown at user limited to the bare minimum. Hence my opinion what is a key factor a program to be successful and easily accepted.

Jaclaz answered better than I could Are you sure one will be using source, prepared with the nowadays BTS DP base- I wasn't The line doesn't hurt, and was easier for me to add it anyway, instead of checking if it's already in presetup.cmd. I can fix it quickly if you think it's a problem. Checking sizes upon completion if fixed now, decided to uncheck all the check boxes and reset windows source when copy is completed. Presetup.cmd is now properly created if it was not in the source. Will upload new version when a few more bugs are fixed. Grub4dos unattended- this is a bit tricky. default /default fallback X title Text mode.... .... savedefault fallback title Gui mode .... The thing is that lines are added to menu.lst, and I don't know what X will be, could scan for it, but that will take time to program. Besides, the above entries are created in pairs for each Windows source added, although the second entry (GUI mode) could be common for all the Windows sources as it will point to the same NTLDR/BOOT.INI. Need to think how to organize menu.lst or reorganize it upon completion. It may be easier just to include a few lines in ReadMe.txt- if you want the second part of Setup to launch automatically after first part is executed then....

It's removing of functionality, which is supposed to be done while messing with the source with NLite, and not by a program, which idea is to transfer already prepared source to USB disk, and make it ready for installation from USB In other words I'd prefer to keep it as simple as possible, requiring user to prepare it's source in advance, using external tools such as NLite.

Thanks Wimb, this was very helpful What I miss is the action of MkMigrateInf2.cmd to make the USB-stick DriveLetter U: So now my first install had shifted drive letters for the 2nd and 3rd partition.It's on purpose. I prefer to watch USB drive letter as indicator if something goes wrong and USB disk is recognized as first, as you know then boot files goes on it etc.. I had cases, when even with rdummy.sys, my USB disk was detected as fixed, because it was the last among many mass storage drivers to load. Had to move it to BusExtenders, where it seems to load fine. The shifted drive letters are easily fixed later on from Disk management, which causes no harm to the installation. Still a good idea to include it, just in case someone prefers to use it. Haven't had tome to fix that. I prefer not to change order as it breaks the logic 1) then 2) ..., but rather use grub4dos options to set default entry once TXT mode entry was executed. Added to to-do list. No plans for this There is a beautiful program Nlite, which does this job. Source is used and copied as it is prepared. Messing with the source is beyond the scope of the program. And Display and Edit of XP Setup Parameters in winnt.sif + useraccount in $OEM$ folder Ditto Source is copied as it is. Same applies for winnt.sif, which is amended ONLY with the entries, allowing installation from USB. NLite and other similar programs are to be used if one wants to manipulate his source and unattended file. Same for $OEM$- if it's there- it's copied. Additionally- many people just want to install the XP source they have from USB, without answering too much questions and presented with information, which means nothing to them. I assume, that whoever knows what winnt.sif is, he should know or at least capable to find what to edit, in order to customize his installation. This is not job for the program. If you remember we have discussed that before on PM Good to read Good catch, I never run out of disk space lately as I was using USB hard disk. Upon completion I will reset all checkboxes and Windows source, then do the size check. Thanks. This is an issue with BTS drivers pack presetup.cmd., which I prefer to resolve in other way- by opening a ticket in their forum. The program simply adds a few lines to the presetup.cmd, which already exists. Thus the difference between ren_fold.cmd and presetup.cmd. But bringing this up reminded me that I forgot to fully cover the case when presetup.cmd doesn't exist. Thanks for the detailed feedback

You should trust your feelings I was in my 'bucket list'

I preferred this part to be in a separate post, as it is important: Credits to jaclaz, cdob and wimb for their continuous help and contribution on Installing XP from USB and not only, without who this wouldn't have happened, and porear for bringing this project up and putting it in the right direction, as well as to everyone, who contributed to the project with ideas, requests or feedback- signal64, andy_le2k, lilas to mention few of them. Thanks to UglyBob, ptrex, SmOke_N, aec and ezzetabi from AutoIt forum for their excellent AutoIt script examples, parts of which were used. Thanks to Anton Bassov for his dummydisk.sys driver and help for reverting it's behaviour to rdummy.sys, which makes USB fixed disks to be seen as removable. Thanks to Tynibit for his excellent work and support on GRUB4Dos, and Bean123 for grubinst.exe and touchdrv.exe. And last but not least credits to creators of all tools, which were used in this project- Grub4DOS, PEtoUSB, HP USB format utility, HDHacker, SysLinux, binifix.cmd(did I mention Jaclaz, cdob and wimb?), QEMU, DRVLoad and sync.exe...

Here comes the first GUI for our little project. What it can be used for adding to your USB stick/disk: Multiple sets of Windows setup files- XP, 2000, 2003, Vista, WIndows 7, Server 2008, Windows 8, Server 2012, both 32 and 64 bit versions are supportedMultiple WinPE2 (Vista and above) based sources from ISO files such as Windows Defender Offline, recent Norton Ghost versions and PE (preinstallation environment) based PC manufacturers recovery disks.Single WinPE1 source, such as BartPE, UBCD4Win, LiveXP and similar WinBuilder projects, WinFLPC etc.Multiple Linux based distributions and utilities from ISO files- Debian, Ubuntu, Fedora, CentOS to name a few, this includes most Antivirus Rescue DisksMany other ISO images as long as they are compatible with grub4dos CD emulation, such as Ultimate Boot CD, Windows 95/98 and most DOS based utilities, Acronis and Paragon boot disks and so onSyslinux boot meny and optionally single source which uses Syslinux or Isolinux as boot loaderWinSetupFromUSB can also prepare Windows XP (2000, 2003) setup files to be installed onto a USB disk. I've put some FAQ and Tutorials. Here is a incomplete list of tested sources. If reporting problems, please attach your compressed log file (WinSetupFromUSB.log) and the exact steps to reproduce the problem. Thanks Warning: Several antivirus vendors detect the included in many versions setup.ex_ and setup_dbg.ex_ as viruses. This is false positive: http://www.msfn.org/board/topic/141734-virus-suspected-in-xp-inst-v047z/ You may need to turn temporarily off your antivirus protection when using the program. Hopefully AV vendors will respond at last to the numerous emails sent and take off those signatures. Downloads and changelog: http://www.winsetupfromusb.com/downloads/

Anyone tried to create partitions on the hard disk during Text mode, hit F3 and restart? If I recall correctly on next run Text mode will give C to the partitioned disk/first partition even though it will not be formatted yet.

intl.cpl is Regional and Language options in Control Panel. Perhaps some wrong data in [RegionalSettings] in your winnt.sif? Have a look.

Install from PE environment, running winnt32.exe or equivalent tool, which will run the same with some adjustments has always been an option. The downsides are, that you cannot distribute this PE build. Now we have 2 options: 1) One builds it himself, this sends unexperienced users to something new, they want simply to install Windows from USB. I assume if one knows how to make PE, he should know how to install Windows from that environment. 2) We make this PE from the Windows source, which goes way beyond the scope of this project. There is third option 3)Make small XP with drivers pack included off the windows source: http://www.boot-land.net/forums/?showtopic=3717 Do not use winnt32.exe, but rather build ~BT and ~LS folders on the target disk from a batch script. Target has to be properly formatted, or include some simple partition tool in the small XP. That's a lot of work and experiments, is it worth?