jaclaz

Not much, but FYI: http://www.boot-land.net/forums/Recovery-Console-t2254.html Hmmm, cannot say, you could try using direct mapping of the image (it must be contiguous) instead of --mem mapping, but most probably the BSOD happens when the Windows driver "kicks in" and finds No device or a non supported device. Supposing that I can be defined "a more experienced grub4dos user", I am willing to try and help, but I am failing to understand the situation in it's entirety, can you please re-describe this second approach? What I got: on the root on the stick there is: grldr menu.lst as follows: title boot.ima map --mem /boot.ima (fd0) map (hd1) (hd0) map (hd0) (hd1) map --hook root (fd0) chainloader (fd0)+1 rootnoverify (fd0) map --floppies=1 boot a super-floppy image "boot.ima" containing: (ntldr above is really SETUPLDR.BIN renamed as ntldr, right?) the "RAMLOAD.IMG" contains: a dirtectory \I386 containing all files from \$WIN_NT$.~BT\ + txtsetup.sif + hiveOEM.inf A typo here?: And grub4dos boots in such a manner that SETUP assigns C:\ to the boot.ima file? Is the above correct? No need to use XP embedded tools, using VDK.EXE instead of IMDISK it is possible to create and format a full hard disk image (as opposed to single partition image) howto is here (as Trick #3): http://www.911cd.net/forums//index.php?sho...19056&st=49 If you give me the exact size (in bytes or in 512 sectors) I can prepare a correct MBR and write a few lines of batch to create and format such an image or, alternatively, create such an empty image and send it to you zipped. jaclaz

If I may, given for sure that #4 is the real missing thing, as Nuhi himself stated, as I see all other ones as not needed/unuseful, but although maybe posed in the "wrong" way, #2 has it's merits. Maybe something similar could somehow be implemented WITHOUT bothering Nuhi, that I guess has better/more important things to do, keeping nlite and now vlite working and up to date must be a hell of a work , by some cumulative effort. What if we find a way to "publish" some "pre-made" lastsession.ini files with a few different "levels" of component reduction? That would be the exact counterpart to the "levels" Silvereyes referred to (by the way the app is obviously 98lite and can still be found on it's homesite: http://www.litepc.com/ ). What we need is a kind of "standard" facsimile with a list of major functions or group of functions with checkboxes to have an easily readable documentation, easily comparable, to let the user know exactly or however with good approximation what features will have the build with each given lastsession.ini, and thus choose which "level" better reflects his needs, even if no "level" corresponds perfectly to the user "Optimized" ones, it would however be easier to "interpolate" settings between two "levels" rather than starting from scratch. For example this: http://www.msfn.org/board/index.php?showtopic=85456 could be the "Bare-minimum" level... What do you think of this? jaclaz

NT4 came with NO native CardBus (32 bit PCMCIA) support anyway. There used to be commercial third party Cardbus drivers/stacks, I guess that they are all discontinued by now, but since you don't have the hardware, that's allright. 48 Mbyte of memory seems a bit under-powered to me for NT 4.00: http://www.msfn.org/board/OS_laptop_t55146.html&st=5 that kind of machines usually had windows 95 on them. Back to your problem: Most probably nothing, but, once said that it is of course not recommended/possibly not working using driver files made for other devices, if you are positive that the card is the same or "nearly" the same, a possible path could be: 1) Get the Win2K drivers for your card 2) Get the Win2K drivers for the "other" card 3) Get the NT4.00 drivers for the "other" card Compare the .inf files of #2 against #1. With some common sense (and a bit of luck) you can find what changes between #2 and #1 can be "translated" into a hacked #3 .inf file, with some more luck it will even work . If there is nothing of note in the .inf files, it is possible that there is something in the actual binaries, this might prove to be more difficult to find, but the above hinted method should apply as well. I haven't checked, but if I am not mistaken the D-Link DWL-650 came in several releases, possibly with different versions of the Prism chip, you sure about that one you found using the same one? To find some "similar" cards, you may refer to the Linux list of "supported" PCMCIA/Cardbus: http://pcmcia-cs.sourceforge.net/ftp/SUPPORTED.CARDS (cards that use the same driver should have the same or however compatible chipset) Or, better yet, this one where chipset info for each card is clearly available: http://www.linux-wlan.org/docs/wlan_adapters.html.gz jaclaz

@snowden the problem is not actually in the bootsector, as said it is very easy to rename setupldr.bin to NTLDR and load it with a "normal" bootsector. The way (direct with renaming, grub4dos or other bootmanager, custom written bootsector) is irrelevant. Problem is the way the actual install process "detects" having NOT being booted from CD-ROM. If you want to experiment a bit, Gray on 911CD forum explained how to hexedit setupldr.bin so that it will use files on \I386 even on hard disk (or stick): http://www.911cd.net/forums//index.php?sho...3784&st=249 Possibly using this approach (and optionally using the Dietmar's modified NTDETECT.COM) could lead to some result. Another possible thing one could test (again FAR above my capabilities) would be to use some kind of "upper filters" or something similar to a modified dummydisk.sys driver: http://www.911cd.net/forums//index.php?sho...181&st=1954 to trick, at least the GUI part of setup to believe files are on a CD-ROM. Finally there is this (rather apodiptical, if I may) post by Disabled Trucker, that got NO followings: http://www.msfn.org/board/boot_install_USB...html&st=104 About the use of a PE environment as said my best bet is on a VERY minimal build, the Winbuilder project has gone as low as 15 Mbytes for a really minimal booting environment with CMD.EXE as shell, since all we need to do is to properly run WINNT32.EXE my guess that a not much bigger build would be needed. I tried to start something out of it, here: http://www.boot-land.net/forums/index.php?showtopic=644 but as often happens, everyone agrees, and noone actually does anything to contribute. However the Winbuilder projects have recently entered a more stable level, and a lot of refining work has been made, so I am still ( maybe optimistically) convinced that someone will soon take the challenge and hopefully deliver some results. jaclaz

If you need a simple one, do have a look at this: http://www.rejetto.com/hfs/ jaclaz

Yep, never said it was faster! All the idea of trying to find other methods was behind the fact that that method wasn't perfect. The link you posted does not work, a "tentative" list of possible methods is here: http://www.msfn.org/board/Installing_Unatt...8.html&st=6 Are you referring to method #3? Nothing has been done for a long time, but do have a look at it, the original thread is here: http://www.911cd.net/forums//index.php?showtopic=17425 I am quite sure that it would be possible to write from scratch a somewhat smarter "loader" or "setup" program running under DOS for 2K/XP, or somehow modify the original files as you suggested, but I am afraid it is far above my capabilities to contribute anything useful on that. Most probably there are some other possibilities, for example finding a way (HXdos?) to run WINNT32.EXE instead of WINNT.EXE on a DOS based OS booted from the stick could resolve the problem of the ~BT folder using the /makelocalsource switch pointing to the HD.... ...or finding a way to boot from the .ISO image of the CD saved on the stick.... Every idea, suggestion and contribution is welcome, even if it eventually it leads to a dead end, every attempt helps understanding something more about the way install works and hopefully will make new ideas/methods come to mind. jaclaz

I have been a few days away and I find that a lot of things have progressed. Congrats to both ilko_t and wimb! @ilko_t I had a quick look at your MBR files, as soon as I have time i'll take a closer look and post my findings. I can see it, it's the first post in USB booting subforum:http://www.911cd.net/forums//index.php?showforum=37 I am afraid your post is not present anymore. Some days ago I visited the CD Forum and was able to read your post there, but now the 911 CD part of the CD Forum is almost empty .... Regards, wimb wimb, he thread you are referring to is this one: http://www.911cd.net/forums//index.php?sho...c=19731&hl= (exactly as ilko_t originally referred it to be) As a general rule, always reference to a thread by it's ID rather that the page where you have seen it listed, posts may be moved around, particularly the 911CD forum has made a new subforum dedicated to USB booting, so posts are being moved from less relevant areas and put in the new one. @snowden As said before, there is the alternate method here using winnt.exe: http://www.911cd.net/forums//index.php?showtopic=16713 that of course does not create the "the ~BT folder onto the usb stick itself" and that can easily be fully automated via batch file. Moreover, as hinted here, it has the advantage of keeping install files on HD: http://www.msfn.org/board/I386_folder_t98414.html @buseeliu I don't get it , you join the board and post here just to say: "Look guys, your method is not good, too difficult, I have no alternate solution, so I cannot help, just wanted to let you know that I am looking for another way?" jaclaz

AGAIN, Grub cannot chainload directly XP, grub4dos can: http://grub4dos.jot.com/WikiHome Alternatively to the method illustrated here, it is possible to insert grub4dos inside Vista bootmanager, or to chainload the Vista Bootsector. All the above is related to grub4dos, NOT grub. jaclaz

For those interested, a link to the "original" thread: http://www.msfn.org/board/Data_recovery_tool_t84345.html jaclaz

For the record, to copy the \I386 directory from CD to the hard disk is a common practice between techs, since NT 4.0 days, it allows for two rather distinctive advantages: 1) installing from hard disk is faster (due to the inherently faster access rate of the HD when compared to CD) 2) should some more files be needed at a later stage, they are all already on the hard disk, so the user (EXPECIALLY of laptop PC's) will not be prompted to "Insert the Windows installation CD" when some driver of other file are found missing. I guess that most OEM installed systems use this method as it greatly simplify remote assistance. With the release of the various Service Packs and Windows Update, the 2nd part of the advantage has of course lost much of it's appeal, unless one makes periodically a slipstreamed-with-all-updates new source and copies it on the hard disk \I386 directory. WHY some means to automatically update or "slipstream" BOTH source installation files and actually installed files it has not being provided still remain one of the biggest Microsoft "misteries". As anyone trying to repair a system that has been updated by means of an "original" not-slipstreamed CD has experienced, it is nearly impossible, your best bet is to have another computer either online and with a fast connection or an archive with the various OS and SP's and burn on-the-spot a CD with the corresponding level of update as the system under repair. jaclaz P.S.: and yes the name comes from the old NT (cannot say if 3.1 or 3.51) CD where there was a \I386 directory for "Intel" based machines and one for "Alpha" ones, and of course the 386 was the first Intel processor to be able to run (maybe the verb "walk" would be more appropriate) the NT code, 32 bit, more properly defined as "IA-32" or "x86-32" family of processors: http://en.wikipedia.org/wiki/IA-32 http://en.wikipedia.org/wiki/Intel_80386

Geodisk appears more like an interface to standard Defrag/Scandisk than an actual "Third Party" defragger, so I guess that you need the ME version of the files anyway. jaclaz

Yes, it seems that at the time of releasing Win3.x Microsoft decided that it should run only with MS-DOS 6.22 (they had a lot of "pressure" at the time from DR-DOS) so the 3xstart is needed. Some details here http://www.911cd.net/forums//index.php?sho...16754&st=31 some interesting little apps/betterings for Win3.x can be found on the same thread: http://www.911cd.net/forums//index.php?showtopic=16754 jaclaz

On some motherboards, capable to boot to "super-floppy" type of device it is possible. You need to format the key WITHOUT a MBR. This way you would of course loose the capacity to boot from motherboards that NEED "HDD" formatting (with MBR). The only possible exception is the "special" MBR/bootsetor that makebootfat has, check here for some details: http://www.911cd.net/forums//index.php?sho...13784&st=44 http://www.911cd.net/forums//index.php?sho...0806&st=134 If the problem is just drive lettering, depending on WHICH OS you are going to boot from the stick there might be other solutions. jaclaz

A small correction, if you don't have a hub you will need a crossover or "patch" cable: http://www.littlewhitedog.com/content-8.html ("normal" cables are "direct" or "straight through") jaclaz

If you just quick formatted the drive, you should try TESTDISK, before anything else: http://www.cgsecurity.org/wiki/TestDisk In other words, what you should attempt first thing after a format is a Partition recovery instead of a file recovery. jaclaz

Just for the sake of a little polemics, from the link you gave (which is aimed to solve another problem that some version of FDISK have, and where the issue about multiple primary partitions is not at all considered) : (bolding is mine) Not very different from my simplified "YOU ARE ON YOUR OWN". Moreover, from a pure lexical standpoint, if I tell you that to drive a nail into a wooden plank you can use a Third Party tool called "hammer", it does not mean that I suggest the use of the tool "hammer" to hit your fingers, although the suggested tool is perfectly capable of doing that. The problem, besides the cases you described, could happen if any app is used that writes to disk using "hardcoded" paths, like D:\, E:\ , etc. if a shift or however a change happened in letter assignments, I am thinking about scheduled jobs like backups or "saving settings", but it could be any similar job, set with a certain existing "drive mapping" that could overwrite something when run once a different "drive mapping" has become effective. Moreover there is "user" error possibility, I mean, if the nth partition is given "E:" if booted from DOS/9.x and "F:" when booted from NT/2X/XP, there is a probability that the user will once delete something from "E:" thinking he is deleting it from "F:".... Of course this can be easily worked around by using on the DOS/9.x "side" Letter Assigner and from the NT/2k/XP one manual drive letter assignment to have same lettering in both boot scenarios. jaclaz

Well, in my experience, error messages, with a particular emphasis on those generated by "microsoft Office related apps" tend to be so deceiving to be in a large number of occasions of no practical use. You will find much sooner what you are missing analizing the running processes with monitor tools as already mentioned and running tools like "Dependency Walker" or similar ones to make a quick list of .dll's required by Outlook. After having run Dependency Walker on the Outlook .exe and .dlll files, you could have some "basic" missing files that you can try adding to the install (those "hard referenced" in the .exe's). Than you fire up Filemon and Regmon filtering out all the .exe's you have running but those you presume create the error and see what they are looking for when running and add any component found missing. For Registry entries you might want to have a "parallel" build (working and with Outlook Express installed) to peek into it's Registry and copy the keys found missing on the "experimental" build. The removal files linked to can be however a good reference for making an "inversed" .inf file, i.e. one that only installs the required files and Registry entries of Outlook Express. Most probably you will need a batch, an Auto-it or VBS script to manage those Registry entries that are generated "on the spot" by the standard MS installer on a "per-machine" basis. Also, for the little I know about WINFLP, since it is a somewhat "limited" version, maybe it is better if you do the experimental work in a full XP (so to be sure that none of the possible WINFLP limits "get in the way") and only later test your partial installer on WINFLP, doing, if necessary the needed adjustements. jaclaz

Cannot say if this is of any help, but here: http://koti.mbnet.fi/digitale/throwoutoe/ is a "stand-alone" OE uninstaller. Since it is in the form of a batch file it is very easy to modify it. Maybe if you monitor with tools like Regmon, Procmon and Filemon from Sysinternals an install with both Outlook and OE, you could determine what parts of OE need to be kept to mantain the functionality you need (and thus you remove the corresponding line from the batch). Fred Vork has a similar (said to be more thoroughful) PE uninstall in the form of an .inf file here: http://www.vorck.com/ie-cleanup.html#oe If you are not familiar with .inf files, here is a VERY good start: http://www.boot-land.net/forums/Useful-inf...-inf-t1966.html I guess starting with either of this bases it should be a matter of a few attempts. jaclaz

If you are really sure those files need to be deleted you can try: http://www.dougknox.com/xp/tips/xp_undeletable_file.htm the above and some more ways: http://xona.com/2004/08/19.html This one links to some specific utilities: http://www.pchell.com/support/undeletablefiles.shtml jaclaz

As a general advice to all, a good idea is to ALWAYS, ALWAYS, and I mean ALWAYS make a backup of MBR and (possibly) bootrecords of all partitions. A very simple GUI utility for this, apart MBRFIX/MBRWIZARD, is Dimio's HDHACKER: http://dimio.altervista.org/eng/ A MBR or bootrecord will take 512 bytes of disk space on a NTFS partition and as much as 64 Kbytes on a HUGE FAT16 partition, you can even zip them together, don't come to me saying you cannot afford the disk space or the no-more-than-five-minutes needed to perform this simple preventive step.... ...and you will thank me for this, should disaster happen! jaclaz

Yes, it is : http://www.msfn.org/board/Fit_Vista_single_CD_t96980.html Basically you need to remove EVERYTHING or very nearly to everything to fit onto 650÷700 Mb. Don't take the following as an offence, and you seem like having used a wise approach to vlite but I see this is your first post, so a few points might be of help, as with vlite I am seeing exactly the same trend that has been on the board for nlite, I don't want to "scare" you, but: 1) nlite and vlite have the goal to remove UNWANTED stuff, once the staff has been removed IT IS GONE (a large number of users first thing remove everything, then post something like "this or that does not work in the build, how can I re-add this or that" ) 2) There is NO practical way to re-add something to nlited/vlited installs, though it is possible, it is very hard to do, and best option is to REBUILD with more appropriate settings. 3) There is NO fail-safe settings (unless you choose not to remove ANYTHING) these very good programs cannot read the mind of the user and warn him he is removing something he will later need. 4) the reduced size of install files is a SIDE EFFECT of the removal procedure, to fit into a certain amount of space you will need to remove LOTS of things. The more things you remove quite obviously, the more it is probable that something will be missing. 5) There is an initial rather steep learning curve, you'll have to make several attempts before finding out which settings are the right ones for your custom build. WRITE DOWN your settings or SAVE the build logs, so that you can review them and (hopefully) find out what you missed in your previous failed attempt. 6) Do browse the board in the appropriate section, even posts seemingly unrelated to your problem can offer a small hint about what could have gone wrong. 7) Take your time, but don't be afraid of testing your customized settings, with today's PC speed it is a matter of minutes to rebuild and test, possibly in a VM like Qemu or VirtualBox, if you are lucky (and you are not going trying to reduce to the minimum the size) you might be able to get what you want in a few attempts. Usually a step by step approach, progressively increasing the number of removed components is the one that "pays" the better. As soon as the new build under test is found missing something you need, you check the differences against last working one, and usually, with some common sense, it is possible to determine which of the few components you added to removal list could be the culprit. Looking for it in a list of tens of removed components can be, again quite obviously, really daunting. 9) Don't give up, maybe you are just one little tickbox away from your "perfect" build 8) But do control yourself, "liting" an OS can become an addictive habit 10) Have fun, that's the main thing. jaclaz

"better" is a very difficult definition, sure it is faster! : don't take my word for it, read Mdgx's take on the topic: http://www.mdgx.com/98-5.htm#WDIW The only possible (unconfirmed) exception could be if you use a German system AND MS money 99: http://www.msfn.org/board/Note_WinME_Defra...y99_t92956.html I guess that this, even IF definitely confirmed, can be solved or however affects 0.01% of users.... also, check #16 here: http://smallvoid.com/tweak/win9x/tweak.html and "MAP THE CACHE" here: http://www.mdgx.com/98-3.htm and, ONLY if you like taking risks AND have less than 64 Mb memory, this: http://www.mdgx.com/98-1.htm#98FAS jaclaz

Are you sure? When did it happen? I have downloaded programs from Microsoft servers through WGA not later than one week ago or so. jaclaz

You mean you tried editing a Registry hive in Notepad? jaclaz

According to their site: http://www.irfanview.com/history_old.htm awd is supported, since version 3.99, though I have doubts that it is the "same" AWD. First app linked to should work, it is the "fax" .awd format: http://www.pictview.com/importWin.htm jaclaz