Converting old asm to masm32

[UncleHenry]

 :dazzled: I guess you took me for a ride...  :dazzled:

[redskull]

For spudsters sake...

Back in the day, there was DOS.  This was "real mode", and you ran one program at a time; each program had full control of the computer, including all memory and resources.  However, DOS provided INT21 services for your convienence, should you want them.  In effect, the INT instruction (in your code) simply jumped to code that prints to the screen.  You could eschew that method and use the BIOS interrupts to accomplish the same thing a different way, or alternativly place characters into the video memory directly if you a glutton for punishment.

Then there was Windows.  This was "protected" mode, in which all programs share the computer.  Basically, Windows is now in control of all the system resources, and each program *asks* to use them.  If you want to input/output, you use the system services provided by Windows, much like using the INT command from before, with two major differences; First, they are NOT optional.  To print to the screen in Windows, you HAVE to use the provided functions, and there's generally no (upstanding) way around it.  Second, instead of using "INT" to transfer control, you use "CALL", along with the appropriate .LIB file (which, in turn, jumps over to the code in the DLL file).

The code from the book will assemble fine, and run in an 'Emulation' type mode under Windows.  When running in the emulation mode, Windows grabs the interrupts, and does whatever's necessary to create the window, position the text, whatever.  For example, in real mode emulation, you can write a character directly to the 'upper left corner' of the screen, and it will appear in the upper left corner of the window , which is obviously not the same pixels.  If you try to use the same code under a 32-bit model, your program will crash (as you found out), because your program isn't playing by the rules.

It's no smear to keep programming in the old-school style;  It will appear to run exactly as it would have 20 years ago, albiet in a console box, and is a good learning experience to figure out how things work under the hood (what interrupts do, how segments work, how to etc).  In fact, most assembly language courses at universities do some sort of emulation of real-mode for thier curriculum.  At best, though, you end up with a brand new 20 year old program with limited features; but, like was said, Windows programming is kind of boring. It can end up being mostly just a whole page of function calls.  But judge things for yourself...


-ac

[japheth]

Why would anyone want to write such nonsense, instead of simply calling WriteConsole() is anybody's guess.

Never heard of DosBox? The little sample is kind of "DosBox lite", although I prefer to call it DMR - Dos Mudwater Revival ...

Calling the little sample "nonsense" just reveals that you probably lack fantasy...

[japheth]

Speaking to hutch in this manner is completely inappropiate and unappreciated. There are proper ways to respond to things and theres improper ways, and you definitely chose the latter

Thanks for your opinion, but I prefer to ignore your valuable hints ... boy!

[Spudster]

Windows is now in control of all the system resources, and each program *asks* to use them.

Thank you for the information.  It's starting to make more sense how it all works.  Just to make sure I understand, Windows implements protected mode, not the CPU?  Or is it part of the CPU, and Windows utilizes the functionality?  This would explain why I've had such a hard time finding source that didn't make any calls to the operating system.

...place characters into the video memory directly...

To be truly honest, this is the type of thing I've been looking for.  Not that I would really use this in practice, only that I wanted to know exactly how it is I input code, then a result pops out on the screen.  I then assume that there is some really low level stuff that takes my input, then translates that to what each pixel color needs to be, which Windows has written a driver for so we don't need to worry about it.  It's much easier to appreciate the hardware I have when I realize how much time has been put into making even simple processes work properly.

Again, thank you.  That cleared up a lot of questions I had.  I see that what I've been really wanting is impossible to do both in practicality and resources (that is, writing my own OS from scratch in assembly and creating my own drivers for the devices).  It's coming together how a program of mine communicates with the OS, which in turn communicates with the hardware.  My mind was stuck in 16bit mode, where I thought I could do anything with the system that I wanted.  Is it then possible to create system files that communicate with the hardware directly, then I can write a program that calls on those?  Sorry about so many questions.  I started learning this about three weeks ago, and haven't been able to concentrate well on anything else since.

[redskull]

Or is it part of the CPU, and Windows utilizes the functionality?

Something like that; perhaps someone with more experience can offer advice.  It definitly requires CPU specific instructions (check out volume 3 of the intel books), but those instructions are designed around an operating system implementing them.

To be truly honest, this is the type of thing I've been looking for.

Then I would say your best bet is to continue on learning with 16-bit mode (there's a whole section on the forum devoted to this).  Windows will emulate your code exactly like a fast-8086 would, and all your bios calls and direct video addressing (:b800, right?) will appear to work as expected, so you can see the play between software and hardware.  You just have to take on faith that Windows is working the same way 'under the hood'; you just don't get to see it.

-ac

[MichaelW]

Make that almost all of your BIOS calls. Under the NT versions of Windows BIOS calls that attempt to access the hard disk (even for read access) will be blocked, and the event wait function, and possibly similar functions, will not work.

[GregL]

This is nonsense of course. However, you'll read this claim very often here, which might tell something about the level of knowledge in this forum ...  green

The insult was uncalled for. You seem to be quite antagonistic toward Hutch and others here lately. I don't find it humorous.

[japheth]

This is nonsense of course. However, you'll read this claim very often here, which might tell something about the level of knowledge in this forum ...  green

The insult was uncalled for. You seem to be quite antagonistic toward Hutch and others here lately. I don't find it humorous.

It wasn't an insult, because it wasn't directed to a certain person, but it also wasn't meant humorous. I prefer honesty over politeness. This is not something which changed "lately". And my opinion is that the average level of system programming knowledge is not that high in this forum, taking into account that it's an assembly forum where on might expect something else.

I'm not here to please you ...

And this is also EOST, because there a sentence in the forum rules which forbids this off-topic small talk in the Campus.

[UncleHenry]

protected mode [...] s it part of the CPU, and Windows utilizes the functionality?

Yes, protected mode is one of the modes of operation of IA32 and IA64 CPUs. It is controlled by bit 0 of the CR0 register (called the PE bit): when this bit is set, the processor operates in protected mode.

When the processor is powered on, it operates in real mode, even if it's a spiffy new 64 bit Core2 Duo. It's the OS initialization code that turns protected mode on. Before the PE bit can be turned on, some memory data structures needed by protected mode must be initializaed, though.

Is it then possible to create system files that communicate with the hardware directly, then I can write a program that calls on those?

Yes, these kinds of programs are Kernel mode drivers. Their code is executed at the highest privilege level (privilege levels are numbered in reverse order: 0 is the most privileged; 3 the least one) and they can interact with the hardware. You can't, however, write a driver whithout interacting with operating system calls. Windows needs to be in control even of what drivers do. Just to name a few examples:

- when a driver needs to allocate memory, it must ask Windows for it
- when a driver wants to be notified if a device requests an interrupt, it must ask Windows for this
- in order for a driver to be "callable" by a program, it must call Windows APIs to "make itself visible" to the rest of the system

You mentioned the idea of writing a program which does all by itself and therefore interacts with the hardware without making API calls. I guess you are thinking this way because, having understood how the processor operates, you think it's conceivable to write everything on your own.

(I've been there myself  :wink having learned the fundamentals of electronic when integrated circuits where a recent invention, I thought about recreating their functionality using only discrete transistors...)

However, keep in mind this: one of the key concepts of a multitask OS is sharing: programs share memory and hardware devices. The only way to coordinate this sharing is by calling common OS services. For instance, you could perhaps cram into a driver code that duplicates the Windows drivers and turns pixels on on the screen. But then Windows would not be able to prevent you from turning them on when your window is in the background or iconized.

and all your bios calls and direct video addressing (:b800, right?)

Redskull, is that so? I thought direct video addressing wouldn't work, but I never checked this. You really think it would?

[Neil]

I,ve used direct video addressing almost from day one, even though IBM (or was it Intel?) frowned apon its use saying that these addresses could change in the future - they didn't, & it still works on Vista (32 Bit).

[UncleHenry]

Thanks, Neil.

[Spudster]

UncleHenry, good explanation of why it's so important to interact with the OS.  That has been a big stumbling block for me while learning assembly.  Now to learn how to interact with the operating system at that level, but thanks to your advice I have more of a direction.  Also great info on how protected mode works.  One goal I have is to create a hex editor, similar to HxD.  I've really enjoyed using it, and I have been curious how a program could get read/write access to the boot sector of my hard drive.  I can only do this though (ps I'm using vista) when I "run as administrator."  So I assume then when I run a program "as administrator" I give it an access level of 0? and if this is so, then I assume there exists and API that would allow me to prompt the user for this access?

Redskull, also thanks again.  I'm starting to learn some simple console (cmd.exe) programs, using macros.  I read somewhere that assembly code can become just a long list of API calls.  I can see how that could happen, being that Windows doesn't really allow direct access to what's going on.  Honestly, I don't know anything about :b800, but it will give me something to study.  So then, is there any way to prompt for user input without calling, or invoking, a windows API, or does Windows handle all that as well?  Also, do you have any good ideas to learn to use the Windows API?  I've tried jumping on the MSDN, but that's like reading a dictionary and most the time I don't even know what I'm supposed to be looking for.  And really I don't even know that much about the Windows API in general (never got into that with my C, C++ programming).

One thing that has me kind of confused is that I think I'm seeing some "high level assembly" in certain programs, being that they have .IF statements and the like.  If I'm correct, doesn't that kind of remove the "assembly" out of the language?  One reason I wanted to learn assembly was so that I could control each register and instruction.  Not that what I would do would be any faster, only that it was what attracted me to learning the language to begin with.

[Neil]

Spudster,
B800h is the start address of the colour graphics adapter, to directly write to it it was necessary to change the ES register to that address, it coud be then written to using string instructions with DI containing the offset to be written to, starting at zero which is top left. Even address numbers are for characters & odd numbers are attributes.

[Spudster]

Spudster,
B800h is the start address of the colour graphics adapter...

Oh.  Great.  Thanks for the information.  So to make sure I understand, each odd/even pair starting at B800h is each individual pixel, or are the ASCII characters programmed into the video card?  I'm looking up my resource list now using "System Information"...  My display adapter is a Mobile Intel Chipset, and there are several ranges of memory for I/O, but I don't see B800h.  I assume that is because the list displays the actual address of the device, while :B800 is the offset.  I'm reading up on that right now.  Again, thanks for the info.