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

I really cannot see HOW that can be a solution to the issue you posted : that is designed to prevent the computer from going to sleep or getting to the screensaver (possibly one locked with password) while examining a machine, WITHOUT changing settings, see: http://www.cru-inc.com/products/wiebetech/mouse_jiggler/ If you prefer it is a solution but to ANOTHER problem. jaclaz

Since ENABLEDELAYEDEXPANSION is explicited, that won't make a difference. jaclaz

Sure, I knew it , hence the "NOT similar" . JFYI, common sharks with lasers are nothing jaclaz

You should find - I believe - a way to "trigger" the start of the program by monitoring system events, in WMI that woiuld be: Win32_PowerManagementEvent http://msdn.microsoft.com/en-us/library/aa394362(v=vs.85).aspx See if this fits: http://fullparam.wordpress.com/2012/09/07/run-a-script-when-the-machine-comes-out-of-suspendsleep-via-wmi-event-consumer/ A suitable third party (I know you don't want this ) is Hibernate Trigger: http://www.desimonesystems.com/suspendtrigger/ jaclaz

My bad I somehow got things mixed up , should have been: I hope now it makes more sense. jaclaz

Hmmm. Apologies accepted , still .... , 100 times : http://tinyurl.com/pl4pnr5 jaclaz

There is a workaround for that "switching" power profiles and one "simulating mouse movements": http://answers.microsoft.com/en-us/windows/forum/windows_xp-performance/windows-shuts-down-after-it-comes-out-of/765bb889-373a-464d-99b1-d78c9b7c584a And here there is a hopefully better analysis of the issue (and remedy): http://www.pcreview.co.uk/forums/hibernation-after-delay-no-timeout-set-t3288430p3.html Or you could try making use of Imsomnia: http://blogs.msdn.com/b/delay/archive/2009/09/30/give-your-computer-insomnia-free-tool-and-source-code-to-temporarily-prevent-a-machine-from-going-to-sleep.aspx See if any of them works/fits. jaclaz

Well, just so you know, that guy sucks BIG at PR. Next time, you'd better hire not a monk who made a formal vow of silence. jaclaz

Normally you don't. You have before you a choice : share your batch publicly (by posting it here on the board as an example) keep it private If #1, maybe one of the contributors of HFSLIP may notice it and decide to integrate it in HFSLIP, or add it to the available options of HFSLIP and host it on the HFSLIP site or decide that it is not suitable for integration and hosting, or decide that the idea is good but re-write your script, etc. Notwithstanding what the good guys maintaining HFSLIP will do, if the batch is published, it can be used "as is" or merely as a source for inspiration by the next peep that will want to tweak *something* in the way HFSLIP builds a source. If #2 the game ends earlier, actually right now, and your nice batch won't have any use if not the one you will use it for. jaclaz