i thought protected mode only applies to cross segment code/data.
for example you can execute any data that is in the code segment but cannot execute it in the data segment

right
unless the local descriptor table is wrong some how
there is a asm example for writing self modifying code the trick is making the code and data segments overlap by changing the ELF header

Actually, I think the correct answer is yes it is dangerous, and so is C ... but only if you don't know what you're doing, and if you're not using a real OS. I remember crashing or BSODing Windoze so many times with simple C programs in programming class ... but the thing is, even if you run those same programs on Linux, it won't crash the system, it'll just say 'seg fault' most of the time.

but even if it BSoD'ed all you have to do is reboot and it will work normally again.

Oh, most certainly ... and that was punishment enough, trust me. I mean we had to complete the assignment by the end of the class with all this crashing going on. Not to mention that the computers were PII or lower running W 95 or 98, and some were so slow that they were unusable or would crash on their own.

Linux: "Oh, it segfaulted, time to fire up gdb"
Windows 9x: "Damn, it BSODed and I just lost my entire environment"

One is clearly orders of magnitude superior than the other.

for real mode your right BUT that's not how protected mode works
here is what intel says about how memory access works in protected mode
http://download.intel.com/design/int...ers/exc_ia.pdf
BTW
DOS 7 (windoze 95) was the last O/S to run in real mode

No, I've found a documented feature:

http://www.embeddedrelated.com/group.../show/5031.php ->

<your_function_return_type> __attribute__ ((section (".data"))) <your_function_name>(<your_function_args>);

windows 3.1 was actually protected mode assisted codenamed "386 enhanced mode" where programs could general protection fault but it is also not completly protected mode.

MrCode -

Your question has certain generated a lot of smoke, noise, half-truths and misinformation

And yes, even some genuine wisdom

Anyway, I think you can safely take away from this discussion:

1. No, you probably can't do any more "harm" with assembly than you can with a high-level language.

Software is software. At the end of the day, it makes little difference if it's written in assembly or a higher-level language. If the OS will let you trash the system, then just about any language will let you trash the system. For example, I can show you a .bat file that can trash Windows NT (no kidding!).

One could argue that "languages" like Java, C# and VB.Net give you additional "protection" - precisely because they're MORE than just "languages". They're a "language" (Java, C#, whatever) plus a "virtual machine" (the JVM, or the .Net runtime). And it's the virtual machine - NOT the "language" - that gives you the extra "protection".

2. Yes, "real mode" and "protected mode" are COMPLETELY different environments.

You simply can't compare the behavior of a C program under real-mode DOS with the behavior of the SAME C program under protected mode Windows.

Again: software is software: the C program under real mode is comparable to the ASM program in real mode; and the same for the C program vs ASM program under protected mode.

I encourage smeezekitty to experiment with DPMI. Both DJGCPP and OpenWatcom let you experiment with C/++ real mode vs. C/C++ protected mode:

http://www.delorie.com/djgpp/
http://openwatcom.com/

Protected mode programming is VERY (read: "fundamentally"!) DIFFERENT from real-mode programming.

It doesn't really matter whether the OS is Linux, Windows or even DOS/DPMI, or whether the language is C/C++ or assembly. What DOES matter is that the address expressed in your application is NOT the actual address used by the hardware.

just a command can trash the system :
now really do not run those commands

As for NX-bit keeping one safe from accidental execution, that's not entirely correct. As an example, return-into-libc is a whole class of BO which functions fine on an NX stack. At the end of the day, you can only do as much or as little harm in C/C++/asm as the system allows you to do. If you are allowed to send a command to format the hdd, you run that risk. If you're allowed to send some kind of wacky overclocking series of instructions which cause your hdd to simultaneously break the speed of light while your monitor flashes the morse code lyrics to boogey fever, thus creating a rift to the 1970s - well.. you get the picture. Seriously, it's very unlikely that you'll accidentally trash your system, but even if you do the worst that happens is you need to reinstall. Most hardware nowadays protects itself pretty well, and as long as said low-level format is recoverable you're just inconvenienced a lot, and more importantly learn "Don't do that"

Anyway, just one perspective.

I figured, just wanted to make sure, though. I have heard of instances where hardware was damaged because of either poorly-written or buggy software, but I think that would mostly apply to things like embedded systems/firmware.

I'm reading a basic x86/NASM guide (that can be found here), and as I understand it, you really wouldn't want to program in real mode anyway, right? Not unless you were writing for some ancient 286 with 1MB |< of RAM, where you really have no choice...

I know that you can trash your file system using either of those commands (in DOS/UNIX-like systems respectively), I was just curious as to whether actual physical H/W damage could occur from poorly written software, but as others have said, this would be VERY hard to do...

I did a rm -r /usr from / I thought I was in /root/temp
luckily the package manager was in /sbin , I had the install disks
at hand and I figured out what I did before rebooting

real mode has some serious advantaged especially on a single tasking system.
for example:
you can do increadably fast screen writes by writing to B800:0 in real mode but in dos
you have to call a protected mode function that writes it for you, and that time could be significint!