jaclaz

If the disk is bricked, it is bricked. If you do not remove (or loosen enough) the PCB and insulate either the motor or head contacts you won't normally have access to the disk interface via TTL. Consider the usual carpenter comparison: To join two planks of wood together you need (at least) three nails (of suitable length) and a hammer. Put the two planks one over the other and drive the nails vertically in both the planks by hitting with the hammer the heads of the nails. Q. I have the hammer but no nails. I tried banging the hammer on the planks really hard, but they don't stick together. A. You need the nails. The procedure REQUIRES that one set (or the other) of contacts are insulated (or the whole PCB is removed). You *need* a suitable Torx screwdriver to losen or remove the screws. If you really-really cannot afford (or procure one) usually these screws can be undone with *any* flat screwdriver of suitable size of which you have filed down a bit the edges, i.e. from: _| || ||_| to / \| |\ / However, quick check list: Is the disk powered?Did you try hitting CTRL+Z?Have you tried inverting Tx and Rx?Are all devices properly grounded?Have you made sure that the USB->TTL adapter provides the right (lower) TTL levels?jaclaz

Actually they are not lying (please read as "not lying more than usual"). It is most probably true that the updates (which doesn't really mean that they won't work, only that they were not intended for it) Also the following statement: is very accurate . These updates are actually intended for Windows Embedded and Windows Server 2003 customers. They do not fully protect Windows XP customers (as well as they do not fully protect Embedded And Windows Server 2003 ones ). Also here: given the amount of issues that previous updates caused (when XP was supported), I have some doubts about those updtes havine EVER being tested (thoroughly) on Windows XP , and of course "significant" without any data is one of those words that can mean anything, you know like these (ALL considered by someone constituting a significant risk to health or safety, before being debunked): http://www.hse.gov.uk/myth/myth-busting/index.htm I like these ones , carrying a parasol at a race: http://www.hse.gov.uk/myth/myth-busting/2013/case204-racecourse-parasol.htm and carrying new shoes without a box: http://www.hse.gov.uk/myth/myth-busting/2014/case248-customers-buying-shoes.htm are reknown as dangerous activities. Nothing to see here, people, move along. jaclaz

There is actually a (wrong ) assumption in the very beginning of this thread. And what is saddening is that it is the SAME assumption that has been forced down our throats by the good MS guys, that a single Operating System can be a one size fits all and all it's user should or must conform to a given behavioural model. NoelC's reported experience is the experience of a particularly knowledgeable software engineer using his computer on the workplace to do professionally whatever professional software engineers are supposed to do. Another user, let's say a kid, with no actual (yet) understanding of the OS, downloading and running (even only to briefly test them) a zillion programs, among which many "rogue" ones, any number of *ahem* diversely obtained and authenticated pieces of software, navigating 2/3 to 4/5 of the Internet, playing every conceivable (and also unconceivable) online or offline game, may have some different experience both on the stability of the OS and on the utility of "registry cleaning" tools. Personally, being (unfortunately) a grown up kid and not (cannot say if unfortunately ) a software engineer, I find that going midway, i.e. using (say) Regseeker and manually reviewing it's output before applying changes/deleting registry keys is a suitable approach. jaclaz

@drugwash Yes, almost, the thingy runs in autoexec.bat WIN.COM /W, see: http://www.msfn.org/board/topic/171878-boot-to-gui-windows-and-not-dos/#entry1078808 http://support.microsoft.com/kb/142544/EN-US so the files should be .wos, but that should only affect autexec.bat and config.sys. jaclaz

I hope you mean that it IS booting (from the PE) WITHOUT clicking noises or slowly. In other words your laptop's hard disk is defective and prevented booting even from a PE, unfortunately something that is rather common (hard disks failing) especially on laptops where the smaller hard disks (thus needing higher "precision") are also subject to shocks and have worse cooling than on desktops.. jaclaz

Naah, that is not at all a gauntlet, it is just a set of statements. This (point 7, specifically) may be interesting to challenge: http://rwmj.wordpress.com/2010/02/18/why-the-windows-registry-sucks-technically/ As well as this one : http://reboot.pro/topic/7681-the-registry-as-a-filesystem/ Though they may make it even harder to choose an approach.... I mean, choose one : IF the Registry is a database, then it makes sense to compact (please read as defragment) it periodically. IF the Registry is BOTH a database AND a filesystem, it makes sense to compact (please read as defragment) it periodically. IF the Registry is NOT a database, BUT ONLY a filesystem, then it makes even more sense to defragment it periodically. jaclaz

I take this back: evidently dencorso's crystall ball needs to be completely overhauled as unlike mine (which needing some fine tuning could not see details as I was expecting) his one provides WRONG details. Yes , seemingly the one in the top left corner is a screw holding the hard disk in place. If you post the actual laptop model, possibly a better photo and disassembling instructions can be found. jaclaz

Hmmm. The Registry is a database. A filesystem is a form of database. The Registry is also (can be seen as) a filesystem. Filesystems are defragmented as an "ordinary" maintenance task (with the exception of the Ext2/3/4 because they are so smart that it is not needed [1]). Databases are compacted (please read as defragmented) as an "ordinary" maintenance task (no exceptions that I know of). If compacting (please read as defagmenting) the Registry is a bad thing, then compacting a database is also a very bad thing to do, as well as defragmenting a filesystem. The good MS guys post deceiving information, then: http://support.microsoft.com/kb/288631/en-us Sent from my common i386 PC using Opera 12.15 and bragging about it. jaclaz [1] At least this has been *true* until the good Linux guys exited, after several years, "denial mode" and some defragmenting tools for the Ext2/3/4 filesystem wre made available.

IF it is a SATA disk drive (dencorso crystal ball is working better than mine , as he was able to see through it the actual PC, and thus know it is a desktop and has a SATA disk drive) The one with "thicker" wires, coloured in black (2 wires), red and yellow is a more general description, commonly IDE/PATA hard disk (3.5") have this: http://en.wikipedia.org/wiki/Molex_connector whilst SATA hard disks (BOTH 2.5" and 3.5") have this: http://en.wikipedia.org/wiki/Serial_ATA#Power_connectors The connector for IDE/PATA hard disks 2.5" is integrated in the data connector, like: http://www.addonics.com/products/adms25ide.php jaclaz

Usual NT based vs. DOS based Windows , NTFS vs. FAT32, Godzilla vs. King Kong flamewar in 5,4 3, 2, 1 ....0. jaclaz

And AGAIN the idea of a forensic examination revolves around NOT changing ANY settings. The thingy you found was primarily devised to allow "first responders" to have a possibility of transporting a system "on" and without it self-locking due to a pre-set timeout such as screen saver or workstation lock. Also the "other" tool used for such transport makes no sense whatever: http://www.cru-inc.com/products/wiebetech/hotplug_field_kit/ outside it's intended scope. As an example I still have to see: in "normal" IT to have the actual *need* to unplug and move a server without switching it off, but I can well understand it's usefulness in forensics.jaclaz

Let's see if this is clear enough : CDIMAGE 2.27, as well as 2.03, 2.05, 2.12 are NOT available. The last character in the above sentence is a "full stop" or period. If - on the other hand, the CDIMAGE 2.27 is *needed* to rebuild a Windows 2000 ISO, then it is NOT needed as it is possible to recreate that .iso using CDIMAGE 2.39 hexedited to change some data, used with the provided switches. jaclaz

No, it is not a good idea to try an "unknown" tool of which you have no specific experience with. Ghost usually means Symantec Ghost which is an extremely powerful tool (and thus potentially destructive, in - no offence intended - the hands of someone not fully familiar with it). The fact that you have a "source" folder is a good thing instead, because if we can pinpoint what the issue is and if the fix requires a "fresh" file you have it readily available and, in the worst case you can try reinstalling the OS. The generic idea is (1st possibility): 1) diagnose the issue 2) find a procedure to fix the diagnosed issue 3) apply the given procedure or (2nd possibility) 1) Reinstall the Windows 98, hoping that the files on disk are "good" Philosophically, I always tend to favour first possibility, but in some cases, it may be easier/faster to go for the second, the choice is entirely up to you. These may come handy: http://support.microsoft.com/kb/250928/en-us http://support.microsoft.com/default.aspx?scid=kb;en-us;179756 Still, doing a scandisk is STRONGLY recommended anyway, and attempting a set of simple, common, repair attempts, such as attempting restoring a previous copy of the Registry: http://support.microsoft.com/kb/221512/en-us costs nothing and can have no bad consequences (the worst that can happen is that your windows would not boot, but since it doesn't boot now, it is not really a worse situation ) BEFORE EVEN THINKING of reinstalling, make sure that you have available space on disk AND that all needed files are available. Content of the Windows 98 CD: http://support.microsoft.com/kb/188428/en-us jaclaz

Good (which means bad),the situation is as it has been diagnosed. Now the issue is what is the actual issue with "normal" Windows and how to fix it (short of starting from scratch by re-installing everyting. If you REM out those lines in Autoexec.bat, you should be able to boot to "normal" DOS. Do check also the mentioned settings in MSDOS.SYS. Once you are in plain DOS, nothing prevents you from typing at the command prompt: CD C:\Water4zEWATER4Z.EXEand you will access your program as before, but this time, when you exit from it, you will get back to the DOS command prompt. From that you can do first thing a check of the disk (what is likely to have happened, coincidence at the time you removed the battery is that a file or more got corrupted) using SCANDISK.EXE. Then, you can start checking the "diagnostic" WIN.COM option /D: http://support.microsoft.com/kb/142544/en-us Please understand that if one or more files have been corrupted on disk, you will need anyway a source to get the corrupted files from (original CD or similar). Can you post some specs on the hardware (motherboard, BIOS, which internal connection it has, like for floppy, a second IDE channel, etc.)? jaclaz

Lostinspace2012, no real need to get upset. I trust the user about running Windows 98, it would be "queer" that he confirmed seeing the Windows 98 boot screen I posted. From what I understand: The OP is describing (with some difficulties) two DIFFERENT workflows/sequence of events , one that happened BEFORE a given date/event (which cannot possibly be just removing the battery) and what happens NOW (or AFTER). Probably BEFORE -> the PC booted to DOS and the DOS program was started from Autoexec.bat. Upon exit Windows was loaded "normally" AND, if from the booted windows he clicked on the program shortcut on the desktop then the same program would run in full screen DOS. Upon exit the user was back to the Windows desktop. In such a setup a "common" user would not see a difference between "first run" of the program and subsequent runs (if not for Windows desktop loading faster )AFTER (NOW) -> the PC boots to DOS and the DOS program is executed from Autoexec.bat. (exactly as before) but when the WIN.COM is invoked to load the Windows 9x, it crashes, causing a reboot loop.jaclaz

That's why I suggested typing in "Ver." But nobody listens to me :-) It will tell you which version of DOS is really installed, and therefore what Windows is actually present. otherwise, this is all just a wild goose chase. Does VER typed in a FULL SCREEN DOS window inside a WIndows 9x provide anything different from the output of the same command typed when booted in plain DOS on the same machine? jaclaz

Well, no, it's serious and JFYI, Wiebetech has a reputation for making good. reliable, professional tools (that often come at a rather steep price ) As a professional tool it has it's uses, as explained in the quote I provided. jaclaz

Maybe there is a communication problem. On a fully working system: IF you are in Windows and runnning a full screen DOS program, pressing ALT+ENTER will flip between the full screen and a windowed DOS. IF you are in DOS, pressing ALT+ENTER will do nothing.What actually happens if you press ALT+ENTER? It is also possible (though rare) that the system has been configured to boot to DOS (in MSDOS.SYS BootGUI=0) and in autoexec.bat there are lines *like*: C:\whatever\mydosproggie.exeC:\Windows\WIN.COMThis would execute your DOS program and when it exits, load the Windows GUI. If you check your autoexec.bat and you find something like this, it would explain what you describe happened before, and would also explain what happens now IF we assume the hypothesis that *somehow* that WIndows 9x install is "botched" and when the WIN:COM is invoked the machine reboots because of this. How EXACTLY are you accessing DOS now? Can you use EDIT.COM ( or TYPE) to inspect the file AUTOEXEC.BAT? jaclaz

I don't know. I have run (or actually have assisted running) in the good ol' days several (at the time) "high" end graphical workstations for technical designing/drawing (think Bentley, Autocad, 3d Studio and similar) running NT 4.00 or Windows 2000 and never experienced that kind of issues. Maybe the size of files was not that big, and surely the machines were "top quality" (think Adaptec SCSI controllers and 10,000 or 15,0000 RPM disks) but never had issues of relevance (fresh boot needed in a few hours work). Maybe we were less advanced in engineering or just plain lucky . jaclaz

I will try again. From what you describe (there are several possibilities) on a WIn 9x system: The system is configured to boot to DOS (and NOT to WIndows) The system is configured to boot to DOS (and NOT to WIndows) AND it has in Autoexec.bat (or more rarely in CONFIG:SYS) a line directly invoking a DOS program The system is configured to boot to Windows (and NOT to DOS) The system is configured to boot to Windows (and NOT to DOS) AND it has in the startup folder, in the Registry (or more rarely in win.ini) an entry invoking a DOS program runnning in full screenNo matter if it boots to DOS or Windows, you will see anyway the BOOT SCREEN (Windows Logo) like this: (the boot logo is embedded in the system file IO.SYS and is shown anyways depending on a setting in file MSDOS.SYS) see: http://www.mdgx.com/msdos.htm (that would be Logo=1) Then if you are in case #4 above you should see, even briefly the desktop appear and by pressing ALT+ENTER you could swithch form the full screen DOS program to it. It is possible (though it cannot happen because of a battery removal) that you have now in that file a setting of BootGUI=0 (which will load the command line DOS) and then a setting (say in AUTOEXEC.BAT) that loads automatically the program. Normally if you are in this latter case (#2 in the previous list) you can exit the DOS program (and get to the DOS prompt) and type WIN [ENTER] to load the Windows GUI. jaclaz

How exactly does the thingy boot? (normally, without any intervention, like when you switch it on?) It boots to DOS or to the Windows GUI? Is the program executed in a (Full screen) Dos box? (i.e. what happens if you press ALT+ENTER?) http://www.computerhope.com/issues/ch000020.htm jaclaz

With all due respect for Windows 7 (and somehow less for 8/8.1 ), I have never had issues with NT 4.00, with Windows 2000 and not even with XP. Overall in my personal experience (runnning 24/7 over many years) - which does not include Vista/7/8/8.1 - I would still rate Windows 2000 as the most stable OS I ever experienced, but slightly so if compared to XP, and if I had a crash, it was due to some stupid driver (or failed/failing hardware). http://www.msfn.org/board/topic/155290-windows-8-deeper-impressions/?p=1022946 So, happy about your "crashless" experience with 8.1, but I (respectfully) disagree with your comparison with crashes of one decade ago, which are something that I have failed to notice, maybe we could talk of those around two decades ago, which - due to the accelerated passing of time in computers would be IMNSHO comparing the reliability of - say - a 2014 Lexus against that of a Model T: http://www.newyorker.com/archive/1936/05/16/1936_05_16_020_TNY_CARDS_000161110?currentPage=all jaclaz

Personally, I would try dividing the issue in two. Temporarily, disconnect the other drives and see if ME ends up the installation correctly and boots fully. Then, if this succeeds, experiment with changing back the BIOS settings, adding the other devices, etc. It is possible that the issue (whatever it is) is limited to second reboot after install and once this phase is over you have the possibility to change something "back". jaclaz

Yep, that's the idea behind delayed expansion. (though the name is IMHO counterintuitive, as with delayed expansion on and ! you get the "current" value, whilst with % you get the value it had "before" entering the FOR loop). See if this other source is more clear: http://www.robvanderwoude.com/variableexpansion.php jaclaz

I am failing to see the actual need to do the splitting and rejoining of the files. IF (as I understand it) you do all that work to just replace a few bytes in the files, as posted in number #14 gsar or hexalter are much easier, faster and need not temporary files. jaclaz