Converting old asm to masm32

[FORTRANS]

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.

Hello Spudster,

   Video memory for the CGA modes 0, 1, 2 ,3, 4, 5, and 6 starts at a memory
address of 0B800:0000.  The MDA mode 7 is at 0B000:0000.  The EGA/VGA
modes are at 0A000:0000.  Those are real mode segment offset addresses.

   In the 16-bit sub-fourm, HATEM asked a similar question in the thread,"scrol
text but there is a problem?"  and I offered an example to show how the text
mode 3 sort of works.

   Note to Neil, maybe the different memory locations mentioned for the various
IBM cards would cause IBM's warning?

Steve N.

[MichaelW]

Spudster,

Ignoring the pre-EGA/VGA adapters, B800h is the segment address of the display buffer for the alphanumeric modes. Your system information memory listing may lump all of the display buffer ranges together as 0xA0000-0xBFFFF, where the range is expressed as absolute addresses. For an example, here is a dump of the first 128 bytes of the display buffer contents when the DOS Debug program is using the display buffer to display a dump of the display buffer (sorry, I can't think of a less confusing description :lol ).

Code Select Expand


-d b800:0
B800:0000  2D 07 64 07 20 07 62 07-38 07 30 07 30 07 3A 07   -.d. .b.8.0.0.:.
B800:0010  30 07 20 07 20 07 20 07-20 07 20 07 20 07 20 07   0. . . . . . . .
B800:0020  20 07 20 07 20 07 20 07-20 07 20 07 20 07 20 07    . . . . . . . .
B800:0030  20 07 20 07 20 07 20 07-20 07 20 07 20 07 20 07    . . . . . . . .
B800:0040  20 07 20 07 20 07 20 07-20 07 20 07 20 07 20 07    . . . . . . . .
B800:0050  20 07 20 07 20 07 20 07-20 07 20 07 20 07 20 07    . . . . . . . .
B800:0060  20 07 20 07 20 07 20 07-20 07 20 07 20 07 20 07    . . . . . . . .
B800:0070  20 07 20 07 20 07 20 07-20 07 20 07 20 07 20 07    . . . . . . . .


The attribute value 07h specifies a black background and a white foreground.

[Spudster]

FORTRANS and MichaelW, great insights.  I did a little more reading into how VGA works, and that took care of it.  Now I understand how a screen works in text and graphics mode.  Not that I'll ever program something to place specific characters in memory, but I have just really wanted to know.  If you're here then I'll assume you understand what I'm talking about.

It's incredible that so much goes into the display.  As I type this I'm looking at the little faces above the editor making all their movements, and what I see is the CPU writing data to each of those pixel locations.  As I think about it, I realize there is more that goes into it.  But at least now I have a stable ground to work with.  Interestingly enough, the more I appreciate what my computer is doing, the simpler I like it.  I run vista, and a week ago I decided to strip it of all it's colors and transparencies.  Now it just looks like an old 98 OS.

I think one last question will clear this completely up.  To get information to an output device, information is written to a memory address.  Now, is it that the information is really written to the memory at that address and the output device has access to that location in memory, or is it that the CPU thinks that the information is being written to that location in memory but really it's being sent to the output device?

[MichaelW]

It would depend on the device. For example, the original diskette drive subsystem used DMA to transfer the data between the adapter and memory. The CPU was involved in setting up the transfer, but not directly in the actual transfer. Hard disk drives at one time commonly used Programmed I/O, where the data was transferred by the CPU, between a 16-bit I/O port and memory. AFAIK more recent hard disk drives use DMA, but of a type that is very different, and much faster, than what was used by the original diskette drives.

[sinsi]

You've got the I/O address range (0 to FFFF), old-style ISA bus (out 3c4,1).
Then you've got memory-mapped I/O (anywhere upto the 4GiB limit), new-style PCI et al (mov e000f000,1).
There are also adapters that use memory addresses e.g. the b800 video memory (and c000, the video BIOS).
Nowadays, video cards (for an example) have a linear buffer, which maps a whole screen to a memory address.

[FORTRANS]

Hi,

   In the "good old days" of DOS, the I/O poots mentioned by sinsi were
used to access the serial port, the parallel port, the keyboard, and set
up the video modes.  And other things as well.

   Memory was used as MichaelW said to access the floppy drive.  And
putting data onto the video screen.  And other things of course.

   With more modern O/S'es, you fill a buffer in memory with your data,
and tell the operating system to put it in its final destination.  I/O is now
a privileged process, and specialized drivers that conform to the model
used by the operating system must be used in the 'normal' user cases.

HTH,

Steve N.

[UncleHenry]

So I assume then when I run a program "as administrator" I give it an access level of 0?

No, it does not work this way. Processor privilege levels and user rights are totally unrelated concepts.

Let's start with the privilege level (usually abbreviated as CPL): every Windows process contains both code which executes at CPL 0 (most privileged) and code which executes at CPL 3 (least privileged). The code you write and code from Windows DLLs like user32, etc. are executed at CPL=3. When you call a Windows API, the API code may need to call into the Windows kernel to do its work (not every API does). If this is the case, it uses a particular instruction to transfer control to an address into the kernel and, at the same time, change CPL to 0. With earlier processors, the instruction is an INT 2fh (not 100% sure of the int #), with newer processors and newer Windows (I think XP or later) is a sysenter, which is more performing. Think of INT 2fh/sysenter as CPL changing JMPs.

The registers and memory data which control where the INT 2fh/sysenter transfer control to, are themselves protected: code running at CPL=3 can't change them. This prevents CPL 3 code from setting up a CPL 0 transition outside control of the OS.

Remember I wrote ant INT 21h would cause a fault. The reason INT 2fh does not is that Windows sets up the memory data for vector 2fh so that CPL 3 code can issue it, i. e., gives "permission" to CPL 3 code to issue it. However CPL 3 code can't change *where* that INT would JMP, so execution goes on at a point well known to the OS.

After the INT/sysenter, the processor executes kernel code at CPL 0, which carries on the API work and then returns to CPL 3 with an IRET or sysexit.

This goes on throughout the life of almost every process.

The processor is set up so that instructions needed to touch the hardware like IN and OUT can only be executed at CPL 0 (at CPL 3 they cause a fault similar, to the one for INT 21h I wrote of before). Most memory ranges used by memory access devices are protected as well, with the same result.

The implications of a user being or not and administrator comes from the Windows security model, of which my knowledge is limited. AFAIK, it has different effects.

First of all, keep in mind that a process is always associated with a username: normally the one used to log on to Windows. When you log on you start a session and all the processes you launch are associated with that session and that user.

Certain APIs behave differently depending on the user access rights. There are windows configuration tools which allow you to say "user 'Joe' has this and that access right". When a process is launched by a Windows logon session for Joe and calls an API, the API code checks to see which rights Joe has and behaves accordingly.

Another implication of the security model is that when you create certain resources, like files, you can define which users have access to them. When a process calls an API (e. g. CreateFile) which tries to access the resource, the API checks if the process user has been granted access to it and returns an error if not.

All of this is implemented on top of how the processor works and its rivilege levels, meaning that all this code runs performing the CPL transitions we saw.

As for why the program you mentioned works only when you are an admin, I can only guess.

First of all, direct access to disk sectors can only be performed by the kernel itself or a kernel mode driver. These drivers are called by the kernel and executed at CPL 0.

I'm not sure wether there are CPL 3 APIs which allow direct disk access, I *think* I read something about that in the past. If they exist, they probably require access rights granted only to the admin, which would explain this case. Then they would at some point call into the kernel to do their work.

Otherwise, the program needs to interact with the disk driver. This kind of interaction is also subjected to the security model: user mode code interacts with drivers by means of "device objects". A driver creates its device objects and gets to decide which users can access them, so not everybody can.

The important thing to keep in mind is that this is all about what the windows code does, not about how the processor works and its privilege levels.

[dedndave]

Hey Spud,
   Welcome to masm32.
Ignore japheth - lol.
It will slow you down from learning what you want to know.