jaclaz

Check these seemingly unrelated posts (How to install Vista on USB and on FAT32): http://www.911cd.net/forums//index.php?sho...181&st=1707 http://www.911cd.net/forums//index.php?sho...181&st=1712 they may contain some useful info to work around the 0x0000007b BSOD. jaclaz

Hmmm, you don't have access to Google? http://www.ultimatebootcd.com/ http://www.pendrivelinux.com/2007/03/09/us...x-from-windows/ http://www.pendrivelinux.com/2007/04/02/qe...ent-slax-linux/ http://www.pctechtips.org/QemuSlax.htm http://unix-tutorial.blogspot.com/2008/04/...linux-slax.html jaclaz

There is probably some left over in HKLM\SYSTEM\MountedDevices\ See the "WORKAROUND" (NOT the "hotfix") in this seemingly unrelated KB: http://support.microsoft.com/kb/836662/en-us jaclaz

Actually you should get an error similar to this, if MFC42U.DLL is installed properly: As a great number of threads around, this one has not been finalized: http://www.msfn.org/board/MFC42DLL-Unicode...lem-t35158.html So we do not know if the suggested solution may work or not, however, seen also here: http://support.microsoft.com/kb/259403/en-us that MFC42.DLL and MFC42U.DLL have the same size, a try worth making is the following: 1) download and install the VCREDIST 2) make a copy of MFC42.DLL, renaming it to MFC42U.DLL 3) try registering it 4) try running the app with your fingers crossed... At worst you will have latest VC components updated and the desired app still not working...., since your mileage may vary, make sure to have backed up the system correctly before attempting the above. jaclaz P.S.: and please report back (hopefully ) success or (unfortunately ) defeat, so other people may find this thread and either use the solution or avoid the hassle

Qemu is also a valid option: http://bellard.org/qemu/ (and allows to be launched via batch) When used with QemuManager is as user friendly as any other VM: http://www.davereyn.co.uk/ jaclaz

Why, everyone knows that cars with Red Connelly Leather interiors do eat a lot of gas.... jaclaz

Check the stickies in that Forum. jaclaz

As already mentioned, Connectix Virtual PC (Microsoft Virtual PC was bought from Connectix) up to version 5.1 ran under win9x Operating Systems, though version 4.0 was said to be the last one really working OK under 9x: http://www.designertoday.com/Reviews/2002....indows.5.1.aspx jaclaz

Noone AFAIK managed to do it, PLOP is the only (although experimental) project that got some actual results. An old attempt (for DOS) was left "unfinished" for lack of interest/resources: http://www.911cd.net/forums//index.php?showtopic=18650 You can (if we are talking about XP) using the "XP Kansas City shuffle" or "fake signature" method: http://www.911cd.net/forums//index.php?showtopic=21242 You joking right? nlite is a program to reduce XP install source, it has NOTHING to do with "Live XP cd's" (which are actually usually PE based) or with Virtual Machines. For the record, it does exist a "real" Live XP cd, etboot: http://www.boot-land.net/forums/?showtopic=3890 jaclaz

Hmmm, it would seem to me rather difficult it would boot because: 1) any XP based PE uses a \minint\ structure on HD (instead of a \windows\ one) 2) any XP based PE uses SETUPLDR.BIN instead of NTLDR (Yes, Winbuilder LiveXP is a form of PE ) @test1234 Your best option is reading this threads: http://www.911cd.net/forums//index.php?showtopic=18031 http://www.911cd.net/forums//index.php?showtopic=18045 You do not need to rename grldr to NTLDR (latest releases need modifying to allow that), but you can just add to your existing boot.ini a line like: C:\grldr="grub4dos" and grub4dos will be loaded by NTLDR, and in menu.lst you need only the entry for /minint/setupldr.bin Alternatively, you can change the invoked file in the bootsector: http://www.boot-land.net/forums/?showtopic=2362 You can as well have the PE on the same partition as your XP, but be aware of possible conflicts with other folders, like "Program Files" and the like. jaclaz

Doesn't this get us back to the original suggestion by Yzöwl? There already exist "third party tools" to manage .ini or .inf structured files, like the suggested Inimod, these ones: http://www.nirsoft.net/utils/nircmd2.html#using http://www.spiderharper.com/software/utilities/inifile.htm http://www.otbsw.com/ http://www.otbsw.com/Files/inimod12.zip http://www.ericphelps.com/setini/index.htm the iniman tool in Server 2003 Resource Kit, and God only knows how many more. and even more "complete" scripts: http://www.robvanderwoude.com/batexamples_r.html#ReadINI http://www.robvanderwoude.com/vbstech_files_ini.html http://www.robvanderwoude.com/wshexamples_i.html#I programmers libraries/classes: http://www.codeproject.com/KB/applications/iniutils.aspx http://www.codeproject.com/KB/files/win32f...ilityclass.aspx jaclaz

@ilko_t Just some of my "semi-random" ideas, mind you, but couldn't this be done "internally"? Can we assume that a given file will be on the internal hard disk (and never on the USB stick) only after completion of the text mode setup? Can we (deftly ) combine the above with the "default FILE" command: And with the "configfile FILE" directive? i.e.: 1) We have the normal "menu.lst" in root, it contains only entries of this type: title Win2k install default /2kdefault find /tagfile && setdefault 1 configfile /Win2k.lst title XP install default /xpdefault find /tagfile && setdefault 1 configfile /xp.lst .... 2) the configfile of each OS have only two entries: title text mode WHATEVER IS NEEDED FOR TEXT MODE boot title GUI mode WHATEVER IS NEEDED FOR GUI MODE boot In other words, each configfile only has two entries, 0 for text mode and 1 for GUI mode. Would something like this work? jaclaz

OEM Original Equipment Manufacturer http://en.wikipedia.org/wiki/OEM http://en.wikipedia.org/wiki/Original_equipment_manufacturer http://en.wikipedia.org/wiki/Original_equi...turer#Computers here it is usually used as in the underlined definitions: In practice OEM operating systems are limited to be used on a given system by the License or EULA, but some may employ techniques to detect specific hardware to enforce respect of the EULA (End User License Agreement). ISO is an institute for standards, usually when talking about PC's and CD/DVD we refer to ISO as .iso (the file extension normally used for data images of CD/DVD's) conforming to the ISO9660 standard: http://en.wikipedia.org/wiki/ISO_9660 Ideally one should have THREE kinds of (optical) media: 1) Operating System install media, something that will install the base operating system (and nothing else) 2) A recovery environment, i.e. something bootable and useful to repair (minor) problems of the installed OS 3) An image of the system pre-configured (what you originally asked for) Of course whilst 1) and 2) above will fit on a single CD or DVD, a complete image of a configured system will be spanned across several CD's/DVD's, though some compression of the data is possible, a very rough estimate would be something more than half the size of the data to be saved, this can be widely variable based on a number of factors, say that if you have an 80 Gb hard disk, (NOT NTFS compressed) and 40 Gb free, the 40 Gb data, once saved will need about 20÷22 Gb of optical media. It must also be taken into account that when working with a "spanned" image or backup, if you lose one of the discs in the set, you won't be able to restore properly. You will need some time and patience to grasp the ideas and experiment with them, the three "topics" I outlined should be taken in exam one at the time, in order not to mix too much one with another, please choose one, and we'll try and help you with that one, once you get the hang of it, we'll go on to another one. jaclaz

It does exist, it is actually called "batch files". Seriously, you might want to have a look at the UXP project for Winbuilder: http://www.msfn.org/board/project-uxp-t113249.html http://www.boot-land.net/forums/?showtopic=3651 Though it currently uses nlite as "source tweaking sub-engine", you can replace it anytime with your custom .scripts. jaclaz

I may have been too laconic: The idea was of a direct answer, lke "None on your list, this other one", rather than an "add this to the list", that one being what in my personal opinion is the best, of course your mileage may vary. jaclaz

sorry, double posted by mistake. jaclaz

Actually besides writing in BIG, FRIENDLY letters you seem to fail to describe how did you actually setup your machine, which services have you installed, and which settings you are using, how the lan is setup, which FTP app you are using, etc. . Would this be useful: http://leenux.org.uk/lpackham/smbclient/ You can try using this: http://winscp.net/eng/docs/introduction it is also a FTP client. or core FTP Lite: http://www.coreftp.com/ to see if an "alternative engine" changes the behaviour. jaclaz

@cdob Well, if winnt32 is not to be used, it's better to use the "known to be working" mutiboot method: http://www.msfn.org/board/Install-XP-from-USB-f157.html In that method, migrate.inf works. Would adding cfadisk.sys or dummydisk.sys filter drivers work? + http://www.boot-land.net/forums/?showtopic=4701&st=6 You must be right about gray's reports, that would account for the "stop" fusan is experiencing with the write protect key enabled. But we still need to understand why there is a difference with the 4 Gb key and the 16 Gb, would it be possible that on USB sticks FAT16 is so faster when compared to FAT32 that it makes the difference? I wouldn't think so, FAT32 has not any "complex" structure as NTFS has, from what I know is nothing more than an "improved" FAT16. What could maybe make a difference is "quality" of the sticks involved, if the 4 Gb belongs to "top range" and the 16 Gb is of the "cheap ones", that could make a whole world of difference. See the measured performance on this (alas rather oldish) comparison: http://www.hardwaresecrets.com/article/384/3 http://www.hardwaresecrets.com/article/384/4 I guess that since there is a great number of small files when installing, access time and read speed would be the most useful parameters to judge. To remain among OCZ products, the OCZ Rally is almost 20 times faster than the OCZ Roadster in access time, and, assuming that read speed would be roughly proportional to the measured write speed (irrelevant in our case), the difference is anyway more than 3 times. @fusan Performing a quick test with HDTACH may confirm or debunk this latter theory: http://www.simplisoftware.com/Public/index...?request=HdTach the TRIAL version should have enough features to do the access time and read tests. jaclaz

Unfortunately, NO. For some "marginal" things it is possible and relatively easy: http://www.msfn.org/board/problem-with-dig...ra-t120469.html but that one is one of the most "complex" parts, it is simply not worth the hassle to spend hours or days to try re-adding it, test, fail, try adding something else, test, fail....you've got the idea. You really have NO choice but re-running nlite. jaclaz

NTVDM.EXE "sounds" to me as meaning DOS (16 bit) software. It is probable that you need to setup some particular "compatibility mode" , but since you tried and failed, you can try, supposing that the problem is within the installing routine, to extract the files inside the installer and attempt a manual setup: http://legroom.net/software/uniextract You can also try running an old DOS (not Win32 Console, a 16 bit DOS app) and see if the problem with NTVDM is the same, Registry Viewer: http://paullee.ru/regstry is an app that I found needing the NTVDM engine (on 2K/XP), see here: http://www.msfn.org/board/HIMEMSYS-exists-...1.html&st=2 In this seemingly unrelated thread: http://www.boot-land.net/forums/?showtopic=5105 you can find a list of the files that should be needed for 16 bit programs, cannot say if it can help you. jaclaz

Not really my field, but maybe you need something like this: http://www.msfn.org/board/a-sample-autouna...ood-t90286.html http://www.msfn.org/board/a-sample-autouna...6.html&st=6 somehow edited/modified jaclaz

The 16Gb MBR appears correct, being 0C it is a LBA FAT32 partition. The 4Gb is not the best way, it probably uses the NT extension to FAT to allow for 4Gb, at the expense of 64 kb clusters, partition type is 0E (FAT16 LBA), I would re-format it as FAT32. Some info: http://www.win.tue.nl/~aeb/partitions/partition_types-1.html But of of course any of the above is unrelated to the problem you are experiencing, truth is I have no idea why your particular BartPE behaves as you describe. Let's wait and see if cdob or someone else comes out with some ideas.... jaclaz

Hmmm, did you use PEtoUSB: http://gocoding.com/page.php?al=petousb Last time I checked it, it only formatted as FAT16 and thus with a limit of 2 Gb. No, grub4dos should have not any relevance. The only possible difference between a 4 Gb and a 16 Gb may be in the partition type used, a 4 Gb can have both a CHS and a LBA mapped partition, a 16 Gb may only have a LBA one. Save the MBR from both the sticks, use HDHacker (pointing to Physical Drive), compress them in a .zip file and attach the file, I'll have a look at it. Just for the sake of experimenting, can you try the migrate.inf and/or the setupreg.hiv on this new 4 Gb stick? jaclaz

Hmmm, did you use PEtoUSB: http://gocoding.com/page.php?al=petousb Last time I checked it, it only formatted as FAT16 and thus with a limit of 2 Gb. No, grub4dos should have not any relevance. The only possible difference between a 4 Gb and a 16 Gb may be in the partition type used, a 4 Gb can have both a CHS and a LBA mapped partition, a 16 Gb may only have a LBA one. Save the MBR from both the sticks, use HDHacker (pointing to Physical Drive), compress them in a .zip file and attach the file, I'll have a look at it. Just for the sake of experimenting, can you try the migrate.inf and/or the setupreg.hiv on this new 4 Gb stick? jaclaz

Well, there MUST be a reason. The problem is probably in your BartPE, possibly a conflicting plugin or something like that, cannot say. How did you build it? Do you use any "non-base" shell, like XPE or somethng like that? jaclaz