jaclaz

Chip is seemingly MTX208 Vid 1221 Pid 3234 You will need to start trying tools you can find here: http://flashboot.ru/index.php?name=Files&op=cat&id=14 (you may want to use google translate on the above) Chipgenius is not necessarily "exact" and the docs on these utilities are normally VERY scarce. I would try first with this one: http://flashboot.ru/Files-file-304.html jaclaz

Because that poor disk drive developed a defect and later torture was used on it? Who knows? The idea is to try and see. Remember that "something" is NOT "everything", and that when attempting recovering data form a failed drive sometimes you win and sometimes you loose. jaclaz

You were given some. You seemingly did NOT follow them: Here is a nice representation of your HD heads banging against a large chunk of bad sectors: jaclaz

Protects WHAT from WHAT? An UPS will normally do three different kind of "protection": keep the voltage at the same level in case of line peaks (generated by the mains supplier end, typically transient peaks up to 400 V) mantain power in case of voltage too low and/or power completely missing (for a given limited amount of time) filter high voltage peaks (lightning striking the power line) <-this has lmits and depends on the actual model and on a number of other factors* Some will have as a "side feature" the decoupling of data lines (telephone, fax, DSL, etc.). Good as it may be an UPS, the hardware ANYWAY gets a (very short in time) "shock" when the thingy "switches". As always happen there are good UPS's and bad ones as well as good hardware and bad hardware. An UPS generates a "fake" sinusoidal AC wave converting CC from the battery, usually a "squarewave" read (example): http://www.tomshardware.com/news/ocz-ups-battery-backup,7489.html Google for "pure sine wave". *there is something (RARE) that cannot actully AFAIK be "protected" efficiently and reliably which is the event in which a lightning strikes near you building and (wet ground and what not) raises (temporarily) the "ground" potential. When this happens, the ground which is normally and by definition @ 0V may raise (for a relatively long period, seconds, not milliseconds) to a much higher voltage, sometimes enough to fry grounded low-voltage devices The moral is always the same , use as good hardware as you can afford, protect as accurately and effectively as you can both your hardware and data, but for the latter, ANYWAY, implement the Three Golden Rules: jaclaz

Sure. But you need to disconnect the wires. You are in a situation like: ----*----- ----*----- Where the left side lines or dot are (for the sake of the example) the phone line coming in and the right side ones are the line going to a "next" phone socket (the * being the actual "first" phone socket) You have to disconnect the wires on one side of the socket, like: ----* ---- ----* ----- and measure with a multimeter the Voltage on botth the wires still connected to the socket and on the the ones that were disconnected. Use ~ (Alternate Current) and a relatively HIGH Voltage setting on the multimeter, it depend on countries and standard (and actual REN number and what not) but a common telephone line may well be at around 48 V and when ringing well above 100 V. jaclaz

Yep , but in this case (since the thing producing the piped text is a batch and it's output is already an Environment Variable) only. I thought it would have been useful the posted trick as a solution to the "generic" problem "my batch won't accept piped input" . @edisonx Please do READ my previous post. You can pipe the output of your small program into a batch (if needed). More generally you use a FOR loop like: FOR /F "tokens=* delims=" %%A in ('pow.exe 1.23 4.56') DO SET myvar=%%A jaclaz

Not really-really. There are tricks : http://www.robvanderwoude.com/files/readline_2k.txt essentially: ::pipetome.cmd ::A batch capable of accepting PIPE input @ECHO OFF SETLOCAL ENABLEEXTENSIONS FOR /F "tokens=*" %%A IN ('MORE') DO SET Got_From_Pipe=%%A SET Got_From_Pipe jaclaz

Traditionally you use graphite powder to lubricate the tape cartridge innards. It can be bought as graphite powder, but all you need is one of those large mechanicl pencil leads, and a piece of fine sandpaper. (it is sub-otimal as there is clay in them together with graphite, but it is usually good enough) jaclaz

HEy, peeps, comeon... Was it not enough having (thanks heaven only briefly) exported the boot-land flamewar to 911CD? Do we really need to have here a justificatiion for it coming from another at Gena ? Will this nonsense ever end? 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