or just b8 00 4c cd 21 for a simple app (just quits)

If it helps, I believe interrupt 21h is the interrupt you would use to run various DOS related functions... I'm betting that it's "this won't run in DOS" output you got (and thus, why it seemed to you that that was its function) is probably based on the way that modern Windows OSes prefer to deal with interrupts, and computer codes in general.

Remember, interrupts are basically ways of telling the computer to do something at its most basic level (BIOS, or in the case of 21h basic DOS functions). If you do a search on interrupt 21h you'll find some of those functions. I'd reccommend using Assembly programming to access those functions however, as hex editing to make a program is pretty much doing the same thing except denying you the naming conventions (which, of course, is why Assembly was created in the first place; to replace hard to remember opcodes with easy to remember commands, among other things of course).

Anyways, give Assembly a shot. You'll essentially be doing the same thing.

What exactly those opcodes are and what they stand for are also something you could look up. Perhaps try "Intel Opcodes" or something? Anyways, the opcodes themselves have convoluded meanings because many of them are likely shorthand for registers, memory, or other important internal components. They won't all map directly to functions (that is, to something that is being done), a lot will map to the things being done to, if that makes sense. =)

Anyways, as I was saying before, I would suggest keeping it at Assembly level. you're essentially doing what you wanted to do before, but without having to manage physical memory locations and without errors costing you big... I'll explain.

I'm assuming that Windows probably has protections against these kinds of things, but programming directly with opcodes is very dangerous in general, and even moreso on a Multitasking operating system.

In both cases, you'll have the problem of writing the wrong opcode = deleting parts of hard drive, erasing BIOS, invalidating your FAT table, and causing any sort of a million other permanent and nonpermanent problems.

However, in multitasking, you'll also have the problem that memory is already being used by other threads that are running. If you're writing to Opcodes, I'd assume that you are skipping over the protection that languages from Assembly up give in that they won't assign memory to variables that are already in use by variables. In Opcodes, variables themselves don't exist: you are literally writing to a physical memory (drive, etc) location. If that location has something there, something important, then you'll be screwing up something important. Now, I would imagine that Windows wouldn't allow that to happen, but I've never actually tried it myself... and quite honestly, I'd rather not give it a try. Some things in computing just arent' worth the hassle, especially when there's something else that does the exact same thing but with built-in protections (IE Assembly). You must understand that, in essence, you are doing the same thing as writing opcodes with Assembly; you're just given some conveniences to protect your computer as well as to protect your brain from having to remember a bunch of worthless junk.

So in the end, I'd reccommend that you learn Assembly. That's really the way to go, I promise! Besides, Assembly is cooler than Opcodes in general. ;)

I thought the executable part of a com file started at 100h?

Open a command shell and type 'debug'. I forget the DOS code for it now, but you can enter code to save a file and then use debug to hand craft assemlby (it's like narcotic-free dental work).

Thought I had moved this earlier.