jaclaz

You will need to read here, if it's possible, on this site there should be a reference on how to do it: http://www.windowsnetworking.com/ jaclaz

My guess is that it is mostly to annoy you , how would you like M§? jaclaz

Start troubleshooting reading here: http://www.windowsnetworking.com/articles_tutorials/ http://www.windowsnetworking.com/articles_tutorials/trouble/ jaclaz

@GrofLuigi A long shot, but you should have a look at this: http://www.911cd.net/forums//index.php?showforum=43 I seem to remmber an "intelppm.sys" problem solved... jaclaz

For the first part, just read what numebr the BSOD is and report it. For second part, get a freeware hex/disk editor, like, as an example this one: http://www.mitec.cz/hex.html http://www.mitec.cz/Data/XML/data_downloads.xml http://www.mitec.cz/Downloads/HEXEdit.zip Open the DISK - not the partition(s) - loading first 63 sectors. Apert first ones, all the others should be filled with 00's. jaclaz

The two cards look VERY different: http://usedpchub.com/uph/laptop/79-21236-2...play-Board.html http://www.legitreviews.com/article/349/3/ The Inspiron 1100 one should be Intel845 based. Even IF it may work, you will need a BIOS update, and you have great chances of simply making the whole thing unbootable/unrepairable. As I see it, your best choice is finding a replacement card of the same "family" for the e1705, but once you've found it, like on e-bay or on some online shop, before buying it, since they are awfully expensive, examples: http://cgi.ebay.com/Dell-1705-9400-256M-Vi...107111002r15403 http://www.lapzone.com/servlet/the-6208/UF...ron-9400/Detail http://www.impactcomputers.com/uf804.html This appears a bit cheaper, but still a lot of money: http://cgi.ebay.it/256MB-GeForce-7800-Dell...2QQcmdZViewItem I would have a go at it with re-flowing. This may also interest you: http://en.wikipedia.org/wiki/Dell_Inspiron jaclaz

@junksmi Which version of grub4dos did you use? Hooking twice (though possible in latest releases without --unhooking previous hook before) should not be needed. Can you try this: title Boot dos network image find --set-root /w98se-netboot.ima map --mem /w98se-netboot.ima (fd0) map (hd0) (hd1) map (hd1) (hd0) map --hook root (fd0) chainloader (fd0)+1 See if there is a timing problem of some sort, by attempting inserting one or more pause -wait=n statements, see here for a reference by tinybit and Climbing: http://www.boot-land.net/forums/index.php?...c=6231&st=0 jaclaz

No, the flash drive won't probably work, but a grub4dos "virtual" floppy usually does: http://www.msfn.org/board/index.php?showto...82711&st=28 http://www.911cd.net/forums//index.php?showtopic=20543 jaclaz

Something worth a try is also the "Project Dogwaffle": http://thebest3d.com/dogwaffle/products/index.html that has a FREEWARE version: http://thebest3d.com/dogwaffle/free/index.html And PIXIA: http://www.ne.jp/asahi/mighty/knight/ (though latest version does not run on 98, the older 3.3 should work allright): http://www.ne.jp/asahi/mighty/knight/download.htm jaclaz

I doubt that the "old" card would "fit" in the "new" laptop, apart connection a lot of other things, like voltage, hardware ID, BIOS and whatnot may be incompatible. We need more data in order to be able (maybe) to help you. Typically: model of "old" laptop model of "new" laptop ANY number, letter, code, whatever you can read on the "daughterboard(s)" and/or on the main chip on it. Basically: 1) MOST laptops have an integrated video card (NOT detachable) 2) a few laptops have a video card on a daughterboard, using a "proprietary" connector 3) a few laptops have a video card on a daughterboard, using a "standard" or "almost standard" connector, MXM: http://www.mxm-upgrade.com/index.html From what you write, it is probable that all is needed is a re-flow of the daughterboard, something that may be costly (if done by professionals with "proper" equipment) or VERY risky (but cheap ) if done as a DIY job. There was a somewhat "chaotic" thread on boot-land recently: http://www.boot-land.net/forums/index.php?showtopic=6102 where you can find quite a bit of info on the procedure. jaclaz P.S.: this is "specific" for the DELL e1705: http://www.legitreviews.com/article/349/1/ More notebook models: http://repair4laptop.org/notebook_graphics...eplacement.html

Maybe the "k" letter is already "busy" (assigned to the USB HD) when you run the batch. Are we talking about Win PE 1.x (XP/2003 based) or 2.x (Vista based)? With version 1.x drive letters can be assigned through migrate.inf, cannot say for 2.x. jaclaz

Ooops. Sorry, hadn't focused the thread was 9x related. jaclaz

just for the record (and this is not a secret ) you may want to try also FrogAspi, Which is FREEWARE: http://www.frogaspi.org/download.htm#frogaspi http://www.frogaspi.com/products/frogaspi/compatibility.htm jaclaz

Sure, but the actual point why it is NOT recommended is that you have a plain text file (the .bat or .cmd) with the password written in plain text. My 4 years old nephew would probably be able to break it in less time that it takes to say "ANSI escape sequences" jaclaz

See if nircmd works for you: http://www.nirsoft.net/utils/nircmd.html http://www.nirsoft.net/utils/nircmd2.html jaclaz

Another attempt: in the file you posted, at offset 18944 Dec/0x04A00 there is a chunk of data that seems VERY like a "standard" MBR. immediately before, at offset 18432 Dec/0x04800 Hex there is another 512 bytes that could well be the "ST Master Boot Record" but there is a text reference to F10, not F11 and before yet, at offset 16384 Dec / 0x04000 Hex there is a 2048 bytes that do look like a "no-emulation" CD boot sector (invoking BOO.MGR and BOOTFIX.BIN) I would try (in a VM) to create a standard hard disk image, with a "simple" OS, like DOS, on a partition on it, then replace the MBR CODE with either of the TWO MBR codes found. Then, if it works "normally" I would try replacing on the "real" hard disk the MBR code with code from the second one, keeping of course DATA and replicating Disk Signature. Reference to Standard 2K/Xp/2003 MBR and Disk Signature: http://mirror.href.com/thestarman/asm/mbr/Win2kmbr.htm Another thing to try would be to test the found 2048 bytes as "no-emulation" bootsector on a .iso, given that somewhere you have a "BOO.MGR" file or that you can find something that could be it. jaclaz Rule of the thumb to find bootsectors or MBR's embedded in files: 1) search for the "Magic Number" 55AA (more chances of it being an actual boot record signature if it's "aligned" to the right of the hex editor view) 2) check the 64 bytes immediately before: - if they are 00's chances are that it is a MBR - if there is some text "related" to booting, like "No OS", "invalid boot", "non system disk", or the like, chances are that it is a partition bootsector - if there is the text "BOOT" search around 2000 bytes before, if there is the text "CDBOOT" chances are that it is a no-emulation CD boot sector

You are welcome. Maybe I scared you a bit too much , actually most of your concerns are not justified. XP install will put the (few) needed files on the primary partition and all the rest on the one you choose allright. It doesn't matter which of the "two versions" you install first or second, boot.ini will be updated correctly by the second install, the only problem might come if the two versions include different Service Packs, in this case, AS ALWAYS, rule of the thumb is to install all OS in the same order of the dates when they were released. Yes, by default - and I recommend it as being the most compatible setup - out of the 4 entries in partition table of the MBR only two should be occupied: 1 with 1 Active Primary Partition 2 with 1 Extended Partition (this way you will have two "free" for experiments or whatever future needs) And as well, if there is only one Primary partition, it will be set Active automatically. However, as said, I normally use a "pre-boot" to partition the hard disk, and create the primary partition and Logical Volumes. FDISK is pretty much unuseful as it's a bit "dated", the Freedos version is better, though cannot say if it has any size limit. jaclaz

Well, this is strange as well. I mean nlite has users that can be counted in the tens if not hundreds of thousands. The USB_multiboot has as well a very large "base", and an expecially large one coming from eeePC owners. The reports about problems with both, are actually comparatively very few, and usually (no offence whatsoever intended to anyone, just trying to sum up experience ) after some troubleshooting they are solved, and the reason found to have been: 1) in very few cases by an actual problem with the app, that nuhi (for nlite) or wimb/ilko_t (for the install Xp from USB) generally fix in a few days at the most 2) in a large number of cases by people wanting to use features that are simply not there/ or using untested or modified source, or, again, not following instructions and introducing variations 3) in another large number of cases by various PBCAK related problems: http://acronyms.thefreedictionary.com/PBCAK Your problem seem to belong to #2) above. You need a pragmatic approach. Re-create a SP2 nlited version, keeping the components needed for install (see FAQ's). Follow EXACTLY the available documentation/howto's, BOTH for nlite and for the USB install, do not rmove "too much". DO not introduce variations. Try and see if it works. Report exactly the BSOD error (if any). If everything goes well (by any chance) try removing something else, and loop through the steps until you actually get back the BSOD..... ...then redo what you did in your previous attempt.... jaclaz

MicroXP is a known WAREZ release. You won't find assistance or help with it on the Forum. Heck, SP2 was released in 2004: http://en.wikipedia.org/wiki/Windows_XP and there were REASONS for it. While "forcing" SP3 might be overkill, SP2 should be the minimum pre-requisite. jaclaz

Hmmm, according to the IBM support page: http://www-307.ibm.com/pc/support/site.wss...ocid=MIGR-55029 the R51 appears to be "born" for 2K/Xp/Vista, but there seems to be some 98 drivers: http://www-307.ibm.com/pc/support/site.wss...mp;machineind=0 jaclaz

Sure, but I don't see the problem, I mean, let's assume that when one runs your programs has assigned drive letters at least to the drives for which he/she wants an entry in migrate.inf I would like to , but when it comes to programming, you're taking me out of my field of competence. There must be systems, however. There is a current thread with similar (though not migrate.inf related) contents here: http://www.msfn.org/board/index.php?showtopic=124539&hl= particularly, see here: http://www.msfn.org/board/compatible-batch....html&st=22 the John Newbigin version of "dd for windows" has a --list parameter that lists drives very well, though cannot say WHAT it uses. Sample output: dd --list>list.txt 2>&1 rawwrite dd for windows version 0.5. Written by John Newbigin <jn@it.swin.edu.au> This program is covered by the GPL. See copying.txt for details Win32 Available Volume Information \\.\Volume{b0b284c3-8a33-11dd-8781-806d6172696f}\ link to \\?\Device\HarddiskVolume1 fixed media Mounted on \\.\c: \\.\Volume{b0b284c4-8a33-11dd-8781-806d6172696f}\ link to \\?\Device\HarddiskVolume2 fixed media Mounted on \\.\e: \\.\Volume{80cf88c2-8a34-11dd-813c-806d6172696f}\ link to \\?\Device\CdRom0 CD-ROM Mounted on \\.\d: \\.\Volume{5d3e8800-9c1f-11dd-8148-001fc6bb76ce}\ link to \\?\Device\Harddisk2\DP(1)0-0+5 removeable media Mounted on \\.\r: \\.\Volume{80cf88c3-8a34-11dd-813c-806d6172696f}\ link to \\?\Device\Harddisk4\DP(1)0-0+f removeable media Mounted on \\.\n: \\.\Volume{80cf88c4-8a34-11dd-813c-806d6172696f}\ link to \\?\Device\Harddisk5\DP(1)0-0+10 removeable media Mounted on \\.\g: \\.\Volume{80cf88c5-8a34-11dd-813c-806d6172696f}\ link to \\?\Device\Harddisk6\DP(1)0-0+11 removeable media Mounted on \\.\h: \\.\Volume{80cf88c6-8a34-11dd-813c-806d6172696f}\ link to \\?\Device\Harddisk7\DP(1)0-0+12 removeable media Mounted on \\.\i: \\.\Volume{98f06d4c-9506-11dd-8147-001fc6bb76ce}\ link to \\?\Device\HarddiskVolume3 fixed media Mounted on \\.\j: \\.\Volume{98f06d4d-9506-11dd-8147-001fc6bb76ce}\ link to \\?\Device\HarddiskVolume4 fixed media Mounted on \\.\k: \\.\Volume{98f06d4e-9506-11dd-8147-001fc6bb76ce}\ link to \\?\Device\HarddiskVolume5 fixed media Mounted on \\.\l: \\.\Volume{98f06d4f-9506-11dd-8147-001fc6bb76ce}\ link to \\?\Device\HarddiskVolume6 fixed media Mounted on \\.\m: NT Block Device Objects \\?\Device\CdRom0 size is 403259392 bytes \\?\Device\Harddisk0\Partition0 link to \\?\Device\Harddisk0\DR0 Fixed hard disk media. Block size = 512 size is 320072933376 bytes \\?\Device\Harddisk0\Partition1 link to \\?\Device\HarddiskVolume1 \\?\Device\Harddisk1\Partition0 link to \\?\Device\Harddisk1\DR1 Fixed hard disk media. Block size = 512 size is 320072933376 bytes \\?\Device\Harddisk1\Partition1 link to \\?\Device\HarddiskVolume2 Fixed hard disk media. Block size = 512 size is 320062063104 bytes \\?\Device\Harddisk2\Partition0 link to \\?\Device\Harddisk2\DR4 Removable media other than floppy. Block size = 512 size is 134217728 bytes \\?\Device\Harddisk2\Partition1 link to \\?\Device\Harddisk2\DP(1)0-0+5 Removable media other than floppy. Block size = 512 size is 98671104 bytes \\?\Device\Harddisk3\Partition0 link to \\?\Device\Harddisk3\DR6 Fixed hard disk media. Block size = 512 size is 320072933376 bytes \\?\Device\Harddisk3\Partition1 link to \\?\Device\HarddiskVolume3 Fixed hard disk media. Block size = 512 size is 2097414144 bytes \\?\Device\Harddisk3\Partition2 link to \\?\Device\HarddiskVolume4 \\?\Device\Harddisk3\Partition3 link to \\?\Device\HarddiskVolume5 \\?\Device\Harddisk3\Partition4 link to \\?\Device\HarddiskVolume6 Fixed hard disk media. Block size = 512 size is 41940670464 bytes \\?\Device\Harddisk4\Partition0 link to \\?\Device\Harddisk4\DR7 \\?\Device\Harddisk4\Partition1 link to \\?\Device\Harddisk4\DP(1)0-0+f \\?\Device\Harddisk5\Partition0 link to \\?\Device\Harddisk5\DR8 \\?\Device\Harddisk5\Partition1 link to \\?\Device\Harddisk5\DP(1)0-0+10 \\?\Device\Harddisk6\Partition0 link to \\?\Device\Harddisk6\DR9 \\?\Device\Harddisk6\Partition1 link to \\?\Device\Harddisk6\DP(1)0-0+11 \\?\Device\Harddisk7\Partition0 link to \\?\Device\Harddisk7\DR10 \\?\Device\Harddisk7\Partition1 link to \\?\Device\Harddisk7\DP(1)0-0+12 Virtual input devices /dev/zero (null data) /dev/random (pseudo-random data) - (standard input) Virtual output devices - (standard output) Since it is Open Source, you may get some ideas from it's code. jaclaz

No prob. Let us know how it went.... jaclaz

Well, actually the only thing for which migrate.inf is used in the "Install XP from USB" is to be able to assign a letter to the USB stick. This is the only feature needed (making the migrate.inf for a single drive letter) to replace the .cmd. But it might be an idea to add in the future the possibility to also add a given drive letter, say E: (instead of C:) for the First Primary Partition of target system, or however be "free" of assigning drive letters at will or for future, at the moment not thinked about, use. In other words, if it's easy to implement multiple letters, do it, it may come handy, if it's in any way difficult or complex, forget about it. jaclaz

Thanks for clarification. Sure, it is designed to do just one drive. Can you please give an example? But does this create a problem or is it only a "look" problem? Didn't know that, thanks for the heads up. Good point ! Now it comes to the request part . Can we have in the future a version that accepts command line parameters like: MkMigrateInf.exe /Drives=C: that only creates the .inf for C:\ MkMigrateInf.exe /Drives=C:;D:;K: that creates the .inf for given Drive letters Can I assume that your .exe is (and will be in next versions) freely redistributable? It would be nice if we could add it, once the needed feature has been implemented, to the "Install XP from USB" routine. B) jaclaz

Try using psubst: http://alter.org.ua/docs/win/persist_subst/ http://alter.org.ua/soft/win/psubst/ jaclaz