Siginet

OK cool I got it now. What I was confused on was I didn't know I needed both plpbt.bin and plpbtldr.bin. I was getting rid of plpbt.bin and trying to only use plpbtldr.bin... then I tried only using plpbt.bin without plpbtldr.bin. PLoP seems so easy to use... but it is kinda confusing because all of the PLoP files are named very simular. So my next version should be PLoP only. Plus I will probably add support for Vista/Win2008/Win7 as well. I'll also add suport for PE as well. Thanks jaclaz... I don't know if I would have ever figured this all out without you.

@jaclaz You were right about the USB 1.1 speeds being faster when PLoP is used during the USB boot process. I have a computer that is really slow at booting to the usb through the built in USB Boot option in the bios. But when I use the PLoP method it is very fast!

I'll keep messing around with it then. But that plpcfgbt utility you posted would not work on plpbtldr (unless I did something wrong). I was only able to get plpbtldr to work in the default manner... which had way to much stuff to do to get to the usb stick.

Well... I just finished the next version of "Siginet's PLoP USB Boot Manager". Unfortunatlly I think I have to include GRUB4DOS and PLoP. Because whenever I include only PLoP the method to boot from USB is a pain. Way too much involved. I did try jaclaz idea to make it default boot to USB but when I do that PLoP does not work at all unless I boot to Grub4Dos first. Unless we can make a plpbt.bin which can be loaded directly from boot.ini to automatically boot from a USB device... I think we will need to use Grub4Dos. But this is actually fine because now it just boots directly to the USB when you select the option in the boot menu. I also made the possability to include your own grldr, plpbt.bin, or menu.lst. All you do is put your custom files in the same directory as SiginetUSB.exe.

OK... I have successfuly figured out the PLoP only method... but... for some reason it does not go to the same screen where I can just select "USB". It goes to some sort of instsall screen where I need to choose #3... then select Yes... then click #9 for it to restart. Then the computer restarts automatically to the "USB" screen like before. Then it will allways boot to USB until I go back to the install screen... press #5... choose yes... then #9 to restart. Which now restarts correctly. Seems like a LOT of un-needed work. So I'll keep messing with it and see if I can figure out a way to go directly to the screen to choose "USB". Also... the good thing about PLoP only... is the fact I can install it to C:\WINDOWS\PLoP. So it is not cluttering the Root of the C drive.

Yeah I was thinking about the editing of grldr and I think it would not be a good idea. Besides.. with the menu.lst being on the hard drive it will allow users to modify it and put their own stuff in there as well. So I think it's fine the way it is now. Since this should be do-able without grub I will also attempt to do that as well.

Sorry for the late response. I haven't checked this forum in a while. You can use my other program RVM Integrator to do a lot of what you need. I don't care if it is used in a corp environment. I just hope you'd donate: http://Support.SiginetSoftware.com What I usually do is use RVM Integrator. Then you use PowerPacker One by One till you have added all of your OSes. Using the DriverPacks BASE from www.DriverPacks.net Then you compile your iso with PowerPacker. Sorry I have never finished the manual and got too busy to finish PowerPacker to it's full potential. But I do plan on updating it when I have more time.

Siginet's PLoP USB Boot Manager Installer Currently Supports: Windows 2000, Windows XP, Windows 2003, Windows Vista, Windows 2008 and Windows 7. Much thanks to jaclaz for the idea on how to get this to work! This is very helpful if you have created a USB Stick to install Windows from. But you are trying to install on a computer that does not have support in the BIOS to boot from USB HDD. I took jaclaz information and created a simple exe that will install PLoP to your system and add it into the BOOT menu as an option. It is very easy to use. Just launch it... it will ask if you want to install. Click Yes. If you want to Uninstall it just launch it again... It will ask if you want to Uninstall it. Click Yes. I set the Timeout (Countdown) to only 3 Seconds... so be quick to press up/down when the boot screen shows up. I'd rather have the screen only show for a few seconds so it doesn't slow down my normal boot process by much. When you boot up the computer you will see options to boot into windows or "Boot From USB" if you select to "Boot From USB" it will automatically attempt to boot from any bootable usb devices you have connected to the system. This also speeds up the BIOS USB speed on some computers. Some computers only run at USB 1.1 speed during the boot process even though they have USB 2.0 capability. But PLoP loads a USB 2.0 driver that is used instead of the USB 1.1. I plan to add full support for PE environments in the next release. Release Notes: If you use this and find it helpful please send me a donation at: http://Support.SiginetSoftware.com SiginetUSB.zip

Very nice! Thanks guys! Sounds very easy. I think I'll throw together a quick autoit exe with the needed files compiled that will automatically do the needed changes to boot.ini and put the files on the drive or remove them if they allready exist. BTW... what would be the method for vista/win7/2008? So I can add that capability too. I'm curious... is it manditory that grldr be on the root of the hard drive? I tried to put it in boot.ini to launch from C:\WINDOWS\GRUB\grldr... but it did not work. I just figured if it was something to leave on the hard drive it would be nice to have it inside the Windows dir... so that most users would not notice it as clutter on the drive. If it possibly could be launched from within a subfolder it would be great. Also... I could not figure out how to edit the embedded config inside of grldr so I can get rid of the need for menu.lst.

Yeah I have used that method in the past. But I am thinking that we could possibly make it so that we do not need to put to boot files on the hard drive. Basically my idea is that we use a mini iso simular to ilko_t's: http://www.msfn.org/board/2-t139737.html But with a usb driver in it. I think FiraDisk can do this if I understand correctly? This way we could boot into a PE or into an existing Windows Install... Launch a file to setup the boot.ini and restart the computer and get the option in boot.ini to launch the setup which would then act just like an original USB install. It sounds like we have the technology to do it allready... but I don't understand firadisk enough to figure it out.

Yeah I know! It's got me thinking of some great features I can add to a later version of Powerpacker.

I have confirmed that this method does indeed work on CD/DVDs as well! After I created my setupldr and txtsetup files for my disk (Without DriverPacks)... I integrated driverpacks to my disk as well. Then I created some more setupldr and txtsetup files with the driverpacks info in them. I made boot options to install with DPs or Without DPs and they both work fully.

I'm wanting to test installing from usb on a bios that does not allow usb booting By booting into the current windows xp. But I can't seem to figure out how to do this. I suppose I can somehow edit the boot.ini and select grub4dus from the menu... but I don't know how to make it see the usb drive. I'm thinking it would be great if we could somehow utalize ilko_t's small iso method. Tweaked somehow so that it loads a usb driver before launching setup. Has anyone done this? Thanks!

Good idea. When I get home later I'll modify this thread to be more specific. I was kinda in a rush writeing it. If anyone else trys this please let me know. I want to hear how well it worked for you. I really think this is an improvement to the earlier methods of multiboot.

But this is a mini ISO which is very small. It's only 2,752 KB I think just about any computer can handle that.

Ever since USB installs have been made possible I have wanted to make it easier to fit all versions of XP on a stick without wasteing space. With multiboot CD/DVDs this is possible by having all versions of XP on a disk and compileing it in an optimized ISO. But that wasn't very useful for usb sticks. Now this new method is the most clever method yet! And this new method could probably be modified to work on CD/DVDs too. This small tutorial is based on the latest WinSetupFromUSB GUI. ============================ I used Windows XP Professional OEM as my base OS. I opened WinsetupUSB Gui v1 Beta1 found in this thread: http://www.msfn.org/board/2-t139737.html Once you create your first os you will need to modify a few things... 1. create a folder inside "WIN_SETUP\XP_PRO_SP3\I386" called "CONV". Inside "CONV" you will create 3 more folders "VLK", "OEN", and "RTL". Copy these files from your Windows XP Pro OEM disk and place them in the "CONV\OEN" directory (Some of the files may be compressed with _ at the end... you can keep them compressed): dpcdll.dll eula.txt oembios.bin oembios.cat oembios.dat oembios.sig pidgen.dll setupp.ini svcpack.inf (Only needed if you have different apps integrated through svcpack) Follow this same process for the VLK folder and the RTL folder. 2. Now go to your "WIN_SETUP" folder on the root of your USB stick and extract the "XP_PRO_SP3.ISO" to a new folder "XP_PRO_SP3_FULL" Inside the new "XP_PRO_SP3_FULL" folder go into the I386 directory. Rename the txtsetup.sif file to txtsetup.vlk. Inside the txtsetup.vlk file add this line to the [sourceDisksNames.x86] section: 777 = %cdname%,%cdtagfilei%,,\i386\CONV\VLK Also seaarch the txtsetup file for all instances of the above files you placed in the VLK directory and change the first number set to 777 For example Change: dpcdll.dll = 100,,,,,,,2,0,0 To: dpcdll.dll = 777,,,,,,,2,0,0 Now copy this txtsetup.vlk file and name it txtsetup.oen and modify the line you just created: 777 = %cdname%,%cdtagfilei%,,\i386\CONV\VLK To: 777 = %cdname%,%cdtagfilei%,,\i386\CONV\OEN And copy it again name the file txtsetup.rtl then change that same line to: 777 = %cdname%,%cdtagfilei%,,\i386\CONV\RTL 3. Go back inside your WIN_SETUP\XP_PRO_SP3_FULL\I386 folder Copy the setupldr.bin file and duplicaate it 2 more times. Naming all three of them like this: SETUPLDR.VLK SETUPLDR.OEN SETUPLDR.RTL Open each one in a hex editer. Replace all instances of "winnt.sif" with "winnt.vlk" for the VLK and do the same for OEN and RTL. ***NOTE*** You only need to replace the lowercase instances of "winnt.sif"! Change every lowercase instance of "txtsetup.sif" to "txtsetup.vlk" in each setupldr file according to the vlk, oen, rtl extension of the setupldr file. 4. If you had any winnt.sif files for each of the OSes you should rename them (winnt.vlk, winnt.oen, winnt.rtl) and place them in the XP_PRO_SP3\I386 Directory on the USB Stick. 5. Now compile your XP_PRO_SP3_FULL folder into an ISO in the same layout as the old XP_PRO_SP3.ISO file. Your new ISO should have this in it: Directory of G:\WIN_SETUP\XP_Pro_SP3_FULL 12/11/2009 10:18 PM <DIR> . 12/11/2009 10:18 PM <DIR> .. 12/11/2009 10:18 PM <DIR> I386 0 File(s) 0 bytes Directory of G:\WIN_SETUP\XP_Pro_SP3_FULL\I386 12/11/2009 10:18 PM <DIR> . 12/11/2009 10:18 PM <DIR> .. 04/13/2008 10:13 PM 47,564 NTDETECT.COM 12/10/2009 09:43 PM 260,288 SETUPLDR.OEN 12/10/2009 09:45 PM 260,288 SETUPLDR.RTL 12/10/2009 09:39 PM 260,288 SETUPLDR.VLK 12/10/2009 09:44 PM 461,432 TXTSETUP.OEN 12/10/2009 09:45 PM 461,432 TXTSETUP.RTL 12/10/2009 09:41 PM 461,432 TXTSETUP.VLK 7 File(s) 2,212,724 bytes Total Files Listed: 7 File(s) 2,212,724 bytes 5 Dir(s) 1,746,513,920 bytes free 6. Now you will need to modify your winsetup.lst color black/cyan yellow/cyan timeout 10 default /windefault title Back to Main Menu configfile /menu.lst title Second part of 2000/XP/2003 setup / Boot first internal hard disk savedefault map (hd0) (hd1) map (hd1) (hd0) map --hook rootnoverify (hd0) chainloader (hd0)+1 title First part of XP_Pro_SP3 VLK setup find --set-root /WIN_SETUP/XP_Pro_SP3.ISO map --mem /WIN_SETUP/XP_Pro_SP3.ISO (0xff) savedefault 1 map (hd0) (hd1) map (hd1) (hd0) map --hook root (0xff) chainloader /I386/SETUPLDR.VLK title First part of XP_Pro_SP3 OEM setup find --set-root /WIN_SETUP/XP_Pro_SP3.ISO map --mem /WIN_SETUP/XP_Pro_SP3.ISO (0xff) savedefault 1 map (hd0) (hd1) map (hd1) (hd0) map --hook root (0xff) chainloader /I386/SETUPLDR.OEN title First part of XP_Pro_SP3 RTL setup find --set-root /WIN_SETUP/XP_Pro_SP3.ISO map --mem /WIN_SETUP/XP_Pro_SP3.ISO (0xff) savedefault 1 map (hd0) (hd1) map (hd1) (hd0) map --hook root (0xff) chainloader /I386/SETUPLDR.RTL BTW... for some reason whenever I make my USB stick with WinSetupFromUSB Gui I don't have any information in my menu.lst to launch the winsetup.lst file. So I add this to the top of my menu.lst file: color black/cyan yellow/cyan default /default default 0 timeout 10 title Windows XP/2000/2003 Setup root (hd0,0) configfile /winsetup.lst savedefault --wait=2 I think this is everything I did. Hopefully we can add this capability to an upcomming version of WinSetupFromUSB! A huge thanks to ilko_t!!!

Oh ok I understand now. Yeah that does sound easier in a way. But... if we used the other method then we would only have to change the folder name that the files are going to. Since all of the txtsetup.sif files will be pretty much the same. The 990 code would allready be changed to represent the folder where to get the files. Yeah I think we need to play with different methods to figure out which one will work the best. What was wrong with the missing files during GUI part?In my next test I left the oem files in I386 (In my first test I deleted the files from I386). When I did this Windows Gui setup went perfect without any problems. In the end I had a fully operational Windows XP Pro Corp. Then I did 2 other tests with mini ISOs for OEM and RTL which also worked perfectly. Using txtsetup.oem as a file name wouldn't be a good idea, it's already hardcoded and read for other purposes, use txtsetup.oen or something similar. Yeah I was thinking that when I wrote it. Guess we'll have to come up with a different schema for renaming the files. ------- I also think we need to add svcpack.inf to the list of different files as well. Because if someone integrated different programs into the svcpack method. For instance when integrating some oemscan addons for pre activating oem installs.

What's different in this version? I'll test it tommorrow. Thanks

I'm not sure how that would work. Because then we would be overwriting the files. How would we be able to differentiate which files would be the ones copied over in the end? Maybe I misunderstand the idea? Actually everything works perfectly now. Except for winnt.sif not working in the mini iso. Is there a way to make that possible? Actually... maybe it's better to just edit the setupldr.bin to use a different winnt.sif file for each os. So we can have multiple setupldr.bin and txtsetup.sif files on the mini iso and multiple winnt.sif files in the XP\I386 dir. for instance... Rename setupldr.bin to setupldr.vlk (not sure if changing the extension will be an issue) Rename all instances of txtsetup.sif and winnt.sif to txtsetup.vlk and winnt.vlk in the setupldr.vlk file. Rename the winnt.sif file in the XP\I386 directory to winnt.vlk And do the same steps for oem and rtl files as well... setupldr.oem, txtsetup.oem, winnt.oem setupldr.rtl, txtsetup.rtl, winnt.rtl

@ilko_t I placed a winnt.sif file inside the mini iso... but it doesn't seem to recognize it. Any ideas?

OK... heres what I did to test. I had a successful usb stick made from the test version of this wisetupfromusb gui in this thread. It is Win XP OEM. I created a folder "WIN_SETUP\XP\conv\vlk". Inside the vlk folder I placed all of the files that are different from oem to vlk: dpcdll.dll EULA.TXT OEMBIOS.BIN OEMBIOS.CAT OEMBIOS.DAT OEMBIOS.SIG PIDGEN.DLL SETUPP.INI I also removed those files from the "WIN_SETUP\XP\I386" directory so that setup would not look for them in I386 at all. Inside the mini XP.iso I edited the txtsetup.sif file: Added this: [SourceDisksNames.x86] 990 = %cdname%,%cdtagfilei%,,\conv\vlk Plus I edited every instance of the above files I placed in the vlk directory to use the code 990. Windows setup suprisingly went very well!!! I did have 2 files that it could not find in the guimode portion of setup. One I don't remember the extention but it was an oembios.??? file. The other was the oembios.cat file. All I had to do was tell setup to look in the vlk folder I created and then setup was fully successful. So all we have to do is figure out why I got those 2 file errors and we will be able to do this without the need for any dos diskettes! This is a much better method then using dos images. My next test will be to leave all of the oem files in I386 and see what happens. I am pretty sure I won't get those file copy errors anymore... but I don't know if it will cause a problem because setup may grab the 2 files from I386 instead of the vlk directory. But... since they are oembios files I am pretty certain it will be easy for us to fix this issue. So basically there will possibly be 2 methods we can use to successfully do this. Either we have multiple mini iso files. Like vlk.iso, oem.iso, rtl.iso... or xppc.iso, xppo.iso, xppr.iso, xpho.iso, xphr.iso... and so on. Or we can have one iso for pro and one for home which will automatically edit txtsetup.sif in memory. This is very cool! I also think it will work on a cd/dvd as well! Which means we have completely simplified multiboot disks! I wonder if we can specify different names for txtsetup.sif file by simply editing the setupldr.bin file. Any instance of txtsetup.sif changed to prosetup.sif or homsetup.sif? I know this is possible with changeing instances of winnt.sif to different names. This way we could have 1 mini iso with 2 different setupldr.bin files and 2 different txtsetup.sif files. (setuppro.bin prosetup.sif) (setuphom.bin homsetup.sif).

It's been a long time since I have messed with editing SourceDiskFiles and so on. So from what you are saying bove is we still keep the original info in txtsteup.sif... plus add info to also use the conversion files for each os type... plus have them copied to their own folders. So something like this based on your example: [SourceDisksFiles] oembios.bin = 1,,,,,,,2,0,0 oembios.cat = 1,,,,,,,,3,3 oembi01.bin = 1,,,,,,,2,0,0,oembios.bin oembi01.cat = 1,,,,,,,,3,3,oembios.cat oembios.bin = 990,,,,,,,2,0,0 oembios.cat = 990,,,,,,,,3,3 [SourceDisksNames.x86] 990 = %cdname%,%cdtagfilei%,,\corp Or would this work the same... [SourceDisksFiles] oembios.bin = 990,,,,,,,2,0,0 oembios.cat = 990,,,,,,,,3,3 [SourceDisksNames.x86] 990 = %cdname%,%cdtagfilei%,,\corp From what I understand... the sourcedisksnames.x86 section is specifying a new folder on our disk named "corp" next to i386. Which is represented by the code 990. So let's say we do this... in our txtsetup.sif file we modify it so that instead of representing the code it has "***" instead. When txtsetup.sif is loaded into ram it automatically changes all instances of *** to 990 (or the code which represents the OS we are installing). If this would work it would be great. I'll do a quick test by manually editing my files on my txtsetup.sif to look into a different folder on the disk for the files and see if the os completely installs correctlly.

txtsetup.sif: dpcdll.dll = 100,,,,,,,2,0,0 eula.txt = 100,,,,,,_x,2,0,0 oembios.bin = 1,,,,,,,2,0,0 oembios.cat = 1,,,,,,,,3,3 oembios.dat = 1,,,,,,,2,0,0 oembios.sig = 1,,,,,,,2,0,0 pidgen.dll = 100,,,,,,_x,2,0,0 setupp.ini = 1,,,,,,_x,,3,3 txtsetup.sif = 100,,,,,,_x,,3 layout.sif: dpcdll.dll = 100,,102912,,,,,2,0,0 eula.txt = 100,,12793,,,,_x,2,0,0 oembios.bin = 1,,13107200,,,,,2,0,0 oembios.cat = 1,,7382,,,,,,3,3 oembios.dat = 1,,4461,,,,,2,0,0 oembios.sig = 1,,6761,,,,,2,0,0 pidgen.dll = 100,,24064,,,,_x,2,0,0 setupp.ini = 1,,63,,,,_x,,3,3 txtsetup.sif = 100,,480434,,,,_x,,3 I don't think layout.sif matters in this case though. At least when I create my multiboot DVDs... I create one OS on my disk... then duplicate that layout and overwrite only the different files. I never modify layout.inf and each os still seems to work perfectly.

dpcdll.dll EULA.TXT (Not actually needed for install) OEMBIOS.BIN OEMBIOS.CAT OEMBIOS.DAT OEMBIOS.SIG PIDGEN.DLL SETUPP.INI TXTSETUP.SIF (This can be the same on different OSes) WINNT.SIF (If one is used) That should do it. Let me know if you have any other questions. I think if we can get the dos portion working before launching textmode setup it will work perfectly. I can easily help with WinSetupFromUSB GUI by adding some code frome my SetupSourceChanger.exe (Which is made in autoit as well).

I am willing to pay for it if I can find it. I actually was looking for it but could not find anywhere to buy it. I think it only costs like $25 bucks or something like that. But it would be best if there is some kind of free alternative so this method can be put into the WinSetupFromUSB GUI. Basically my idea is that WinSetupFromUSB would be able to place an XP OS on the usb stick using the mini ISO method. Win_Setup Then if they wished to add another simular OS they would have an option to add only file differences. It would then make a folder according to that OS Type inside the OS folder (Like Conv\XPPR). Win_Setup\Conv\XPPR It would place only the files that are different in that folder. In the boot menu.lst it would have each different OS listed. If you selected XP Pro OEM it would launch some sort of dos script that would first copy the files from Win_Setup\Conv\XPPO and overwrite the files in \Win_Setup. Then it would launch the setupldr.bin file inside Win_Setup\I386. This would save so much space on our usb sicks and allow us to fit so much more on it. Plus it would make creating multi-os usb sticks much easier. I was hoping something like this would work through presetup... but I could not get it to work no matter what I tried to do. But if it is done before textmode setup it would work perfectly. Or even if we could figure out a way to load the entire install directory into ram and overwrite with the correct Conv files it would be cool. Then this same method could be accomplished from cd/dvds as well. Which would mean quicker installs from cd/dvds too.