jaclaz

I beg to differ. IMHO the real problem (not only on 98) is/was/will be Outlook Express (re: virus/malware), and the exploits with addresses and the habit of a number of peeps (in perfect good faith) to send to all the people they know the latest "funny" flash/exe/whatever, with a spreading rate (given the theory of the 6 degrees of separation) that outnumbers what a poor little (malware filled) site may do. The real problem with Internet Explorer (besides obviously it's vulnerabilities, know or unknown) are the "ignorance" of users combined with the FALSE sense of security having an antivirus gives them. I mean, you have a nice, brand new high tech kevlar and carbon fiber bullet proof vest. Are you going at 3 AM alone and on foot in one of the "hot zones" in your city/country/whatever shouting: Also, IMHO it is not Internet Explorer (how bad it can be) in itself the instability/resource problem, raher it's integration with Explorer (loop to why a 98 lite is way faster ) jaclaz

No, but if you want I can calculate the impact of posting things before thinking a bit on them (and checking the manual or googling for them) Have you actually checked OPTIONS in Excel? http://www.exceladvisor.net/82/excel-settings-and-options jaclaz

JFYI maybe you can try using a hybrid MBR, info here: http://www.rodsbooks.com/gdisk/ http://www.rodsbooks.com/gdisk/hybrid.html jaclaz

Yep. In practice you are telling grub4dos to ignore BIOS provided drives and try to use it's internal (grub4dos') driver for the ATAPI CDROM. The result (the found CD drive) needs to be "hooked" i.e. made "persistent" in the drive table, or if you prefer until the map is hooked you won't see any (cdn) device, since the info about the found drive is not written anywhere. jaclaz

This is a clear sign that I am too old for this. IMHO there should be a WARNING sign before accessing that page. Having in the same screenshot: (bolding is mine) Is a far too strong shock for my aging heart...... jaclaz

You also checked the MBR ? Or we have another chapter of "The mistery of the vanishing MBR CODE" saga? "GPT, the mistery continues...." jaclaz

Good (which means bad). Now try the: cdrom --init [ENTER] you should have some feedback (post it) map --hook [ENTER] (no feedback on this one) then again the: find ( [TAB] or root ( [TAB] if the cd is detected, than it should be be listed as (cd0). If it is, then cancel the above line and go on with: root (cd0) [ENTER] You should have some feedback about the actual CD, then chainloader [ENTER] Cannot remember if you'll get feedback, I seem to remember yes , something like "Will boot...." then: boot [ENTER] And this would also mean that (by sheer luck ) Ponch was right. jaclaz

Yep. BOOT.INI is "by default": hidden system read only A number of utilities will re-set these attributes, it is very possible that after you edited it (some time ago) you used "something else" that has reset (all or part of) these attributes. Here: http://thpc.info/how/editbootini.html jaclaz

Well, you seem like thinking that the given advice was a form of sadism (having Mobes waiting at the command line for no apparetn reason ). I was actually trying to explain how when you do experiments you need control on what you are doing. As said the cdrom --init is deprecated, in most cases unneeded and in a few counterproductive. No matter whether it (or another pre-made menu.lst entry will work or not) you don't really know what happens as in case of success you don't know what happened, and in case of failure you cannot see what has gone wrong (if not last error). By going line by line you get feedback from grub4dos and by using this feedback you can decide what instruction to give it on next line, and you will have (when actually a feedback is generated) the exact feedback for that given command. A "correct" menu.lst (as simple as possible) entry to boot from CD - we are talking here of a "normal" bootable CD with a "known" filesystem - would be (for the record): title Boot CD/DVD root (cd) chainloader If you run the above with a number of assorted CD's on a "normally" working machine, it will succeeed in, say, 99% of the cases. In the 1% of cases where it will fail, 20% (say) of the cases will be related to a non bootable CD (chainloader failing). The remaining 80% (still say) will be related to the root not being established properly, but you will see the SAME error message as the above. Whether the (cd) device will be available, or we will need anyway a cdrom --init (and possibly needing to --add-io-ports) or not is exactly (in my perverted mind ) the scope of the test. jaclaz

Yep, I am sorry for your misadventure. Those sticks are most probably "good" 2 Gb ones. There are good chances you can "recondition" them to the right size. (2 Gb is better than nothing). Run on them ChipGenius and report the output: http://reboot.pro/4661/ jaclaz

You believe WRONG The idea (mine at least ) is to NEVER use a pre-made menu.lst and ALWAYS use command line when experimenting. In any case the syntax used in that menu.lst is deprecated or plainly wrong (since a couple of years or more) and Mobes omitted to say WHERE he got grub4dos from and the EXACT version he found. Normally if a CD/DVD is present grub4dos will find it and map it as "(cd)" (and NOT as "(cd0)") device WITHOUT needing to use cdrom --init. In any case get latest from here: http://code.google.com/p/grub4dos-chenall/downloads/list Forget the menu.lst! Add the: C:\grldr="Grub4Dos" to boot.ini. Boot and choose the grub4dos option. At the prompt type: find ( and press the [TAB] key. WHICH devices are listed? Explanation: menu.lst is nothing but a sort of simple batch file, it is used to repeat a set of commands that you have already tested successfully on the command line. jaclaz

If you have a 7 based PE you can also run CHKDSK /R allright. Now, all you have to do is to boot PartedMagic (or a similar tool) and see what it sees. Since it is a Vista, you will need to tell TESTDISK to "ignore cylinder boundaries" or the like. This is IMPORTANT. DO NOT use any of the "WRITE" or "fix features f TESTDISK for the moment, just have a look at what it sees. READ the basic tutorial here: http://www.cgsecurity.org/wiki/TestDisk_Step_By_Step You want to start TESTDISK with a LOG file.(you will need some writable media, an USB stick would do). You want to first see the partitions as TESTDISK finds them, then get to DUMP BOTH the MBR and the NTFS bootsector. Then, still assuming you are running from PartedMagic, you need to create a backup of both the MBR (or even better first track or 63 sectors and of the bootsector - 1 sector will do) This can be done with dd (if you need help in using it (yes it is command line) just say so. An alternative (still if you have the 7 PE on a CD) is getting the windows version of TESTDISK, and a disk editor like tinyhexer and have them on the USB stick Check this thread also: (don't worry, you are in a much easier to solve situation than that one, if you can run CHKDSK allright) Once you have the backup of current MBR and bootsector, from within the 7 PE you should be able to run bootsect.exe (the Windows 7 version can also rewrite the MBR code): http://technet.microsoft.com/en-us/library/dd744577(WS.10).aspx Say that your drive is seen as C: bootsect.exe /nt60 C: /mbr will rewrite the MBR code, and: bootsect.exe /nt60 C: will rewrite the bootsector jaclaz

Well, adding grub4dos for tests consists in: writing one single line in BOOT.INI copying one single file to the ROOT of the hard disk BOTH of the above can be "undone" at any moment. IMHO not such a complex thing to try. I would be curious if grub4dos can detect the (cd) device. jaclaz

Yep and faith in something is often capable of keeping one's mind at rest. In my perverted mind something that is implemented with the scope of predicting a failure and succeeds in around 50% of cases is not something to have faith in. If you read this paper: http://www.seagate.com/docs/pdf/whitepaper/enhanced_smart.pdf you may better understand what it was actually designed for (Predictive Failure Analysis BTW). Verbatim from the paper: This is theory. The google study is practice (and actually on a large enough scale to be reliable). A verbatim from it: jaclaz

That is not the installer , it is the CNET downloader , and you can opt-out by un-checking the check boxes allright. The actual installer and the app in themselves are perfectly "kosher" AFAICT. RMPREPUSB has also two test modes, a "quick" one that should be enough to detect a "fake" stick and a "full" one that will take a lot of time but which results can be called "definitive". jaclaz

I don't want to seem grumpier than I usually am , but you came here with a question, an answer was given to you and you use all available methods, programs and OS's on the earth BUT the ones that were suggested. Though unfortunately from what you posted you do seem like a victim of the scam, if you continue do "random" tests with apps/OS and methods I am not familiar with, it is difficult to make sure. FORGET ANYTHING you have done till now. You asked for a Win32 program, which should mean that you can somehow run a win32 OS. Get RMPREPUSB (already suggested you) and NOTHING else. http://sites.google.com/site/rmprepusb/ Use it in a Win32 OS to partition/format AND test your USB sticks. Report what happens. jaclaz

Hmmm. There are quite a bit (I would say the large majority) of very nice and honest peeps on e-bay, so let us NOT generalize, OK? But there are records of tens or hundreds of other far less ethical peeps that sold (or sell still) "fake" large capacity USB sticks. This is NOT necessarily the case at hand, and until we have some tests made the way they should be done (which does not include using NTFS under an OS that has a crappy support for NTFS) it is easy to jump to a wrong conclusion. However for the record the scam is as following: a legit, perfectly working 128, 256 or 512 Mb (and more recently 1 or 2 Gb) stick is used (but not necessarily a "good quality " one) through the manufactirer production tool the controller firmware is set to show a much larger size, typically 16,32, 64 or even 128 Gb most OS utilities will "trust" the USB stick firmware and detect the device with the set bigger size *any* "normal" partitioning/formatting utility will work normally with one of these "fake" sticks when you start writing data exceeding the "real" size of the device, you may have all sorts of queer behaviours, including data wriiten to "thin air" and the kind of "recursive" issues you previously described (but that given the conditions of the test do not justify - yet - assuming that the stick is a fake one) jaclaz

If the HD boots allright, you could add to your BOOT.INI an entry for grub4dos and from the latter try booting the CD (either by chainloading the CD bootsector or by-passing it and directly load the actual loader on the CD/DVD. At least this way we could undestand if the actual optical drive is allright. jaclaz

Wait a minute. A flashing cursor is traditionally a problem with either the MBR/partition table or the bootsector. In other words it is very possible that *nothing* except a handful of bytes in MBR or in the bootsector is wrong (and the actual install/system files are perfectly functional). If I were you I would boot from CD/DVD or USB and check (and save current MBR and bootsector, so USB would be better). Parted Magic would do if you don't have a PE of some kind. Then check status of the disk with TESTDISK, most pobably it can be fixed with no or very little effort. It is NOT advised to use tools like bootsect.exe, MBRFIX or the like because often laptops have "special" MBR code and by restoring "normal" Vista code you may loose access to the Recovery partition (it greatly depends on the actual OEM, model and what not), DELL used to have a "custom" recovery option, and later they migrated it to the "standard" way): http://www.goodells.net/dellrestore/ http://www.goodells.net/dellrestore/vista/ If you are sure that the PC uses this last approach you can replace allright the MBR code (if damaged) with *any* PE. If you have a USB stick handy (and the laptop - as I presume - is capable of booting from USB) we could try using grub4dos to boot the laptop bypassing the MBR and bootsector code (of course if the actual data or filesystem is corrupted there is no way). Another thing that you could attempt doing, once verified MBR and bootsector would be run CHKDSK /R from a recovery console, the normal,. downloadable XP one would do as well on a Vista NTFS. jaclaz

As often happen OT (but not much ) a small app that is useful to do WQL Queries to WMI: WMI tester http://www.paessler.com/tools/wmitester (unlike the Wbemtest that is - to say the least - terrible in usage) jaclaz

To get to that screen you need to press F8 repeatedly and as quicky as possible when booting, like you know: Alternatively, if you can boot another instance of the OS or a PE or a Recovery Console, edit a key in the Registry: http://tweaks.com/windows/36885/disable-automatic-restart/ Until you cannot get the actual BSOD and it's STOP ERROR data, there is very little (please read as "nothing") we can do to help you. jaclaz

Actually, and for the record, IMHO it was Vista that was so many lightyears behind *anything* that Windows 7 in comparison is light years ahead (though actually it is just a few kilometers - maybe - ahead of previous NT based systems). But more generally I fail to see any "lightyear" scale progresses. Let's forget for one moment "professional work" (I mean peeps using as a profession top graphical apps, CAD, animation and video editing programs or rendering, etc.). Let's forget also the eye candy. What has changed in 2011 as compared to 2001 (ten years) for "normal" office or home use? You have an e-mail program, a word processor and a spreadsheet + a .pdf viewer of some kind and an internet browser. You compose e-mails and reply to them, write a letter to be printed and sent via snail mail or faxed, you do some (crappy ) spreadsheet tables, you go on the internet to find something useful or fun. Then at the office you have some vertical accounting program, very often a port of a COBOL program that existed and worked since the dawn of time, or a database of some kind. Additionally you may have some crappy and slow "platform portable" java-based program. (not hat they are particularly bad, only they are just a different way to "deliver" a "same" functionality that has been there since years) I am not a gamer, but from what I can see there hasn't been any "revolution" connected to the actual OS is booted. The hardware is what ? 10 times faster (but in the meantime the OS and, for example, the Office suite has grown in size and complexity with a similar rate), see here: http://www.oooninja.com/2008/05/openofficeorg-microsoft-office-moores.html We still have basically (in most cases) the same way of interaction with the hardware (keyboard/mouse/screen/audio). The only real enhancement is IMHO the "web experience" but this has very little to do with the actual OS, it is a combination of the faster hardware (comprising the actual DSL or however much faster than dialup connection) and of the increased amount of contents the web has to offer. Sure, we have nice graphical effects, Aero and what not, but this is mainly eye-candy, nothing that has changed the usage paradigm IMHO. jaclaz

And additionally (and WITHOUT ANY actual data to back up this statement ) jaclaz's absolutely random observations tend to lead to the conclusion that the more dense (pardon me the pun ) the magnetic media is, the more it will be prone to some kind of failure. Seriously, anyone remember the BIGFOOT drives? http://en.wikipedia.org/wiki/Quantum_Bigfoot_(hard_drive) And as a matter of fact they weren0t even particularly reliable.... The industry is currently "jamming" (I don't think there is a better term for it) increasingly huge quantities of data in the same space (the 3.5" form factor). It is quite natural that with Tb hard disk the precision of mechanical parts needs to be very very high and even the smaller unbalance or tolerance due to wear is more likely to produce a problem. http://www.forensicfocus.com/index.php?name=Forums&file=viewtopic&t=7552 http://www.forensicfocus.com/index.php?name=Forums&file=viewtopic&t=7552&start=16 Usual sound advice: http://www.storagedepot.co.uk/buying_guides/drive_reliability.aspx jaclaz

Yes, there is a general issue with "tutorials" which is the "scope". If the scope is very narrow and no options are given, the "path" is linear, but of course the result is also "fixed". On the other hand when you add options or choices you create "forks" that make the path more complex, and as such less easy to follow. I do understand how difficult it is to find a valid compromise between the need to keep it as simple as possible and that of giving the most options. jaclaz

My crystal ball tells me that it is a 0x0000007b. @infotronix This is EXPECTED as any NT based system needs a boot time drive to hook the .vhd mapped (temporarily and in real mode only) by grub4dos. There are both Freeware and Commercial such drivers, again you need to read and study before, here it is a good place to start: http://reboot.pro/forum/94/ jaclaz