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

It's possible, as long as you pre-boot in a PE. I.e. using migrate.inf, see here: http://www.911cd.net/forums//index.php?showtopic=19663 http://www.msfn.org/board/Forcing-system-d...tt-t125945.html jaclaz

Sure, the point is that is not easy as you think to "assemble" and integrate several different drivers for several different hardware. The driverspack are nothing more than "sets" of common drivers already collected and properly "assembled" together by experts. It is a way to save some time, since most (if not all) the work has already been done, and as said, properly. The board is full of posts by people that have difficulties into integrating even a single SATA driver, and Intel ones, are "pesky". In any case, see this thread: http://www.msfn.org/board/Integration-Inte...ta-t107504.html (which is where I would have directed alto had he asked for a specific Intel driver or for a few of them ) jaclaz P.S.: I edited my previous post to better explain the sense of my suggestion.

Don't want to put you down , but installing 98 on newish hardware may be tricky. Interesting to do and you will probably learn a lot of interesting things while atttempting to do so, but it depends on what you need it for. I mean, if you really need 98 to run natively (for example for directly piloting something attached to a RS232 or something like it, you have no other choices. But if everything you need is just to run a program that needs 98 to run, a better (in the sense of faster to to set up) solution may be a VM (Virtual Machine) like VirtualBox: http://www.virtualbox.org/ See this and see if the solutions proposed apply to you: http://support.microsoft.com/default.aspx?...b;EN-US;Q253912 http://help.wugnet.com/windows2/Hard-Drive...pict492185.html If not, first thing to try is to boot in plain DOS, then try WIN.COM with some parameters: http://www.mdgx.com/msdos.htm (edit MSDOS.SYS to "remain" in DOS) http://www.mdgx.com/secrets.htm#WIN http://www.mdgx.com/newtip10.htm#WINSWITCH Also, booting in safe mode might give you some different results and possibly a hint about what needs to be fixed. jaclaz

Will do, thanks. ...and let you know .... jaclaz P.S.: Quicly tested, it doesn't work (properly) for me, though I see it as a great improvement over the "old" one C:\Downloaded\victor888>regorderdrv all drive letters: C D E G H I J K L M N R mounted drive letters: i C E D R N G H I J K L M virtual drive letters: internal hard disk 1 drive letter: C Errore: impossibile trovare la chiave del Registro di sistema o il valore specificato Errore: impossibile trovare la chiave del Registro di sistema o il valore specificato usb hard disk 1 drive letters: E usb hard disk 2 drive letters: J K L M floppy drive letters: cd/dvd rom drive letters: D remmovalbe drive letters: i R N G H I Legend: = Real situation: 1) internal (SATA) drives: C:, E: 2) CD D: 3) USB hard disk J: K: L: M: 4) Removable (SD card reader, 4 slots) G: H: I: N: 5) Virtual disk (removable - Perioft demo driver) R:

NO, not with nlite. Addition: (to clarify, it is possible, but to support ALL Intel drivers or even worst ALL Sata drivers it will be a long and tiresome process) But you may want to explore the possibilities that "Bashrat the Sneaky" (and many others)'s Driverpacks offer: http://driverpacks.net/ jaclaz

If I get it right, you are asking for a way to type a paasword without it being "echoed" to console. This is possible in pure "batch" files, but it is NOT recommended, see here for some ideas: http://www.geocities.com/leopignataro86/batchfiles/ There are workarounds, in .vbs, depending on the system you want to run it: http://www.robvanderwoude.com/wshexamples_i.html#IEDialogs http://www.robvanderwoude.com/files/ielogin2_vbs.txt Or using third party apps, like (as an example - good as it works both on 9x/Me and NT based systems): Wizard's Apprentice: http://wizapp.sourceforge.net/ http://wizapp.sourceforge.net/manual.html (Editbox HIDDEN) or - more specific - EditV32: http://www.westmesatech.com/ http://www.westmesatech.com/editv.html jaclaz

From the boot image file you posted, it seems to me: 1) it's a boot CD image of some kind (the text CDBOOT is present a number of times) 2) the size is a multiple of 2048 (size of the CD sector) I would try to make a bootable .iso with it and test the result in Qemu (or other VM) - I would try several ones as they tend to be "picky" when it comes to .iso booting I would use mkisofs.exe with something like: mkisofs -v -iso-level 3 -l -D -d -J -joliet-long -R -sysid "Win32" -b boot.img -no-emul-boot -boot-load-seg 0x1000 -allow-multidot -hide boot.img -hide boot.catalog -o .mytest.iso SMINST or mkisofs -v -iso-level 3 -l -D -d -J -joliet-long -R -sysid "Win32" -b boot.img -no-emul-boot -boot-load-size 47 -boot-info-table -allow-multidot -hide boot.img -hide boot.catalog -o .mytest.iso SMINST (just ideas, mind you ) jaclaz

Any recent (meaning several years) motherboard have BIOS chips with a "recovery" part (which is not "flashed" by updates or normal BIOS tools) that's the part that should make the beeps and allow re-flashing from floppy even if all the rest has gone beserk. It is nearly impossible (if possible at all) to "ruin" this part, and anyway VERY unlikely that this happens on three machines. If you have access to some other boards, not necessarily identical, the only necessary thing is that they use the same kind of BIOS chip and same BIOS manufacturer (AMI, AWARD, Phoenix, etc.) from a motherboard grossly similar, like same socket, same "main" chips, you can try using the "other" BIOS chip on one on the failing boards, after having checked thoroughfully that there is not some electrical problem of any kind to the actual BIOS chip socket. The "exchanged" chip won't get harmed in any way, and even if the "recovery block" is not exactly the same, it should be enough to beep or however to change the behaviour of the motherboard when booting. If you see changes you may risk the money to buy the new chips, otherwise it would be wasted money. jaclaz

The date of the bootpart.exe version update that I downloaded is 01/08/2005. As you say the program is rather poorly explained. Now I understand much better what I've done: I've only replaced the part of the bootsector that calls the Operating System, which in fact was damaged. Thank you very much for your documented post, jaclaz! Yep that's the latest, version 2.6 : http://www.winimage.com/bootpart.htm You are welcome. jaclaz