It seems to me that there is more risk to your operating system from out-of-control, demented assembly language instructions, that your cpu has latched onto, than from instructions handed to it by a higher level language. Just the other day, with DOS debug, I accidently hit "T", when the instruction ready to roll was just random garbage, to me, but it meant something to the cpu, which apparently wrote over the names of the files that some of my windows shortcuts (lnk files) were using to decide which icons to display for a number of shortcuts. I discoverd that several of my DOS program shortcuts (and console screens) had new icons, and that the "change icon" dialog, for each shortcut, under the properties dialog, was reporting "can't find the file named ."

After reboot of my computer -- the erroneous shortcut icons were still there. I simply made new shortcuts for these programs -- but who knows what else I wrote over on my hard drive, when I accidently pressed that "T" one time too many -- that I might find out about, unhappily, some time in the future. Fortunately, I pressed "T" accidently, and not "G" -- which could have set a whole chain of unwanted instructions to my cpu, to do who knows what to my operating system.

I am worrying about what I would do, short of re-formatting my fixed disk and reloading my whole windows operating system, and all my programs and data, should I make a mistake that wreaks more havoc.

By the way, I don't keep the complete backup of my fixed disk in the form of a complete duplicate-disk. I just don't have the room to do this, nor do I have a read-write cd drive. What I do is, of course, I keep the cd's from any operating systems and programs that I use (most of the bytes); and, on a second, smaller, fixed disk, I keep, zipped up, installation files for any programs I use that I don't have cd's for (generally downloaded programs); I keep a backup of all my data files in a zip file; and I also back up any configuration files that i need for the programs that I use (which, to make it easier to back them up, I try to remember to keep in folders under my main "data" folder, rather than in their program folders, under my main "programs" folder), in a zip file.

Anyway, do you guys and gals worry about accidently setting a program into operation, that wreaks havoc on your operating system? It is so easy to do this accidentally when assembling with DOS debug. Scary.
Posted on 2002-02-25 11:05:18 by verb
.if zip drive == cdr drive(in the first place)

invoke NoWorries
.else
invoke Worry
invoke TimeToInvest
.endif
Posted on 2002-02-25 16:57:55 by smurf

Anyway, do you guys and gals worry about accidently setting a program into operation, that wreaks havoc on your operating system? It is so easy to do this accidentally when assembling with DOS debug. Scary.

I'm not scared, I run win2k ;). The only thing I have seen crash
(my) win2k box has been unstable ring0 code... which I got rid of
when I ditched my sblive and got a terratec (creative aren't too
good at writing device drivers it seems).

As for your icon problems, it might have been the icon cache that
has become corrupted, that happens every now and then on 9x.
Tweak UI can rebuild the icon cache. You might want to run a
scandisk first if you've had a crash, though.
Posted on 2002-02-25 18:01:01 by f0dder
Thanks smurf, and f0dder.

Unfortunately I don't think I can put a cd r/w, an upgrade to Window 2000, or a broadband connection, in my budget yet.

Even tho my DOS debug mistake didn't crash my computer, I thought it would be a good idea to run Norton Disk Doctor on my fixed disk. Thanks for that advice, f0dder.

My icons look ok now.

I seem to remember it may have been a LODSB instruction that i accidently executed, but I could be wrong, and I don't know what operands were involved; and my assembly language vocabulary at this point is pretty much limited to mov, inc, and dec, anyway. Tho I haven't yet assimilated what lodsb means, I'll might get around to it some time in the future. Meanwhile my computer seems to be working ok -- so far. Thanks again.
Posted on 2002-02-25 20:11:55 by verb
hm, lodsb from a dos VM shouldn't have much effect. The icon
b0rking might just have been a coincidence :). While there were
some things (that I can't remember) that would consistantly fubar
my icons on 9x, it also happened sometimes at random... I think
especially when the icon cache got large it would do weird stuff.
Posted on 2002-02-25 20:16:21 by f0dder
Thanks f0dder. I could be mistaken about the LODSUB though. I might have seen that some other time, waiting by the door; and maybe it was some other creature that darted out to take a romp about the neigborhood, the time that I carelessly opened the door.
Posted on 2002-02-25 20:22:46 by verb
You know, it may be harder to do this kind of stuff in a HLL, but not impossible. Today's compilers are pretty smart, doing things like bounds checking, but it's still possible to crap on yourself. A buffer overflow could clobber instructions with random data, then try to execute it. :)
Posted on 2002-02-25 21:20:08 by S/390
Ah the ever insiduous segmentation fault:)
-> What is more scary is the one that gets away!
Posted on 2002-02-25 21:27:42 by -T-
Unless against the greatest of odds a highly improbable set of circumstances stacked up against you, I sincerely doubt that one single random CPU instruction caused that much damage, especially to information on disk. System calls to file access routines require a fair ammount information set up before hand, and even bios disk routines need specific parameters passed to them.
As for what may have happened if you'd pressed "g" while running debug, well chances are that within fifty harmless instruction, the processor would encounter an invavlid opcode. If you were under dos at the time, then you computer would just hang, and if you were running Windows, then the system would catch the exception. In either case, the most you'd have to do it reboot.
My point, though, is that if your system experienced that much coruption, then a random CPU instruction is a poor explaination. I would recommend that you analyze the task you were performing more thouroughly in order to make sure you don't make the same mistake in the future.
Or.....you just had some really bad luck :)
Posted on 2002-02-26 17:32:26 by Canite
I agree with Canite. You would have to be Stephen Hawking to 'accidently' execute that many valid instructions and system calls in a dos vm to actually do any damage to a file. There aren't enough interrupts that actually work in Win9x to even worry about. Fodder is probably right about ShellIconcache being fragged. As for the added safety of a HLL, I don't see anything different between:



DeleteFile('c:\windows\ShellIconCache');

and

invoke DeleteFile, ADDR szShellIconCache


Actually I think a mis-typed line in a .bat file is probably more dangerous than masm. del commands in a dos vm don't end up in the recycle bin.
Posted on 2002-02-26 18:04:39 by rdaneel
Day of wayward instruction was around 2002feb20. Shelliconcache acc to directory and property sheet was last modified on 2002feb08. Hmm, it was created on 2002jan12.

I don't know what shelliconcache if for, tho. Its name is suggestive, but combined with the dates, it doesn't make much evident to me, as I'm sure I changed some icons via both windows> view> options> file types, and *.lnk file or *.pif file "change icon" buttons, within a day or 2 previous to today, 2002feb26 -- and any write to the file would change the "modifed" date, wouldn't it? So it wasn't written to recently even tho i changed icons recently. So its purpose is eluding me. I think this discussion is getting a bit over my head now, but thanks for pointing out the existence of shelliconcache.
Posted on 2002-02-26 21:20:18 by verb
I've fixed up the icons on my windows 95 computer. And I have Tweak UI for it. But I just learned, when installing windows 98 se on my second computer, that 98 se doesn't come with tweak ui or power toys, and that Microsoft recommends not using the tweak ui that comes with windows 98 (first edition), with windows 98 se. Can I count on windows 98 se to be less likely to develop "icon-incongruity" ??
Posted on 2002-02-27 08:30:30 by verb
One instruction *can* wreck a lot of havoc... "rep stosd" in a dos
app under 9x can take down the entire system if you're unlucky.
And "out" commands... mmmmh :).
Posted on 2002-02-27 09:46:42 by f0dder
Now some more icons just got replaced by erroneous ones, for no reason that I know of. I just looked at windows explorer and either my computer or desktop, or both, i forget which, had a wrong icon. Odd. Tweak ui fixed the problem tho.
Posted on 2002-02-27 14:05:20 by verb
For that matter c:\con\con from the run prompt can crash the whole system too on win9x.
Posted on 2002-02-27 15:04:50 by rdaneel
rdaneel writes
------------------------
For that matter c:\con\con from the run prompt can crash the whole system too on win9x.
---------------------

It can? I don't have a directory named con, with a file in it named con.* .. So I don't see how. Because of my skepticism, I'm tempted to learn the hard way.

Also, the run prompt, when you call it up, doesn't usually turn out to have actual executable filenames placed in it at random (just on-purpose); the area of so-called free memory that would be next to execute when t or g is pressed, after debug is loaded without an argument, very well may.

There will tend to either be something left over from the last time you used the run prompt, or there will be nothing there. Even if you should key in some random letters at the run prompt, they are unlikely to turn out to be the name of an executable program file. However any random sequence of 8 bits that happens to be in the first area of "free" memory space when you execute debug without an argument, has a larger chance of being an byte that the processor recognizes as a being a machine instruction, than whatever you have in the run prompt turns out to be an actual executable filename.
Posted on 2002-02-27 15:39:46 by verb
Verb, The con\con bug is an old Win9x bug that involves accessing dos device names. If you type in c:\con\con at the run prompt and hit ok, your computer will blue screen. Give it a try. It doesn't hurt anything if you save your work first. Kind of like the CrashOnCtrlScroll thing in W2k.
Posted on 2002-02-27 16:29:17 by rdaneel
Very amusing rdaneel.

I remember now, from the olden days long ago when lots of people used DOS, that you aren't supposed to use con as a filename because you need it when you want to pipe something to the console or something.

But I never knew that in windows 9x typing c:\con\con would crash the whole operating system. Windows 9Posted on 2002-02-27 19:08:47 by verb
It has been fixed with patches, winMe probably has the patch
applied by default.
Posted on 2002-02-27 19:16:33 by f0dder
Verb,
You're absolutely right that if you execute code in at a random address (that is, any address that hasn't been intentionally prepare) you will probably execute a good number of valid instructions, but chances are, they will be harmless and meaningless, though I will concede that it is conceivable to have residual code still resident, but again (and I'm sure this issue is growing stale) it's unlikely that file access would take place.
Just for fun though, try generating a file of random bytes. Disassemble it, and take a look at how many invalid opcode you get. Keep in mind that DEBUG (if I recall) doesn't actually point out invalid opcodes.

Fodder,
I'd be the last to argue that it's difficult to hang a system. I think we all find out how easy it is the first time we attempt to use pointers, but disk access by mistake...that's a different story.
Regardless, since I don't use my computer to monitor a nuclear reactor or naivgate an oil barge, I don't consider locking a processor to be such a terrible ordeal. (Though the boot time of modern OS's is a bit more troublesome than yesteryear :) )
Posted on 2002-03-02 22:23:17 by Canite