I mean does it use the CPU to access MMIO to put pixels on the display without having other hardware (e.g. GPU, etc.) follow-up after it.

When Windows 98 boots, it loads an image by whatever program launches (Winload.exe?) and decodes the image and writes to the MMIO device to the display. A GPU is not needed for this, but Windows 98 has device drivers for GPUs. I assume it works like this:


Here are the two questions:

1.When Windows 98 boots and shows the flagship, splash-screen image by default (or any user-defined image), does it have the CPU decode it and write it directly to a framebuffer/VGA/VESA software middleware (driver) to put the pixels on the display and avoid using the GPU if a GPU driver loaded?

2.If no GPU driver is detected, can Windows 98 run completely fine (the OS itself) without any GPU and just have the CPU write to the framebuffer (not considering stuff like OpenGL/DirectX/etc.)?

In simpler words, does Windows 98 operate 100% with the CPU and needs no GPU (except for maybe OpenGL/DirectX high-end graphics manipulation/hardware accelerated drawing/etc. for games, video decoding, etc.)? 3-D games probably use GPU rapid graphics accelerating with OpenGL/DirectX, so it's unlikely the CPU does anything but write to the GPU for this. But the shell/GUI and basic functions of the OS seem to be very basic and lacking any acceleration, and possibly just are drawn with the CPU alone using some sort of display drawing low-level software for pixel manipulation?

Note that I am saying "GPU", but we can consider that to mean any non-CPU hardware that writes to the display. CPUs can write directly to the display without any GPU, but going further than this entails MMIO, low-level programming, specifications, and electronic/computer engineering.

  • Geeze....are there any supported drivers for something this old, unsupported and most likely a security risk waiting to happen? – mdpc Sep 19 '14 at 20:37
  • Sure. I have an old rig with 98 and a "GPU" you can call it ... it's a hardware device that can implement OpenGL/DirectX and do graphics manipulations without the need of the CPU. My question is, if there is a GPU driver, does it use it to do simple 2-D drawing of the GUI and such, or does it just use the CPU and whatever VGA/VESA/etc. driver or such for handling drawing logic? It's a simple OS (compared to XP), but reverse engineering it is still pretty time consuming and delivering few answers on my concerns. – user370301 Sep 19 '14 at 20:38
  • "Note that I am saying "GPU", but we can consider that to mean any non-CPU hardware that writes to the display." -- Before it was enhanced and called a GPU, the hardware interface in PCs used to be called the "display adapter" or "graphics adapter", e.g. MDA, CGA, EGA, PGA, VGA. There has to be HW to convert the memory contents (i.e. framebuffer) into a video signal or a format for DVI/HDMI – sawdust Sep 19 '14 at 23:47

A little bit of history will help you understand how things worked in the Windows 9x world.

Since the Intel 80386, processors have had two "modes" of operation: Real Mode and Protected Mode. When you first turn your computer on -- even a modern Core i7 gaming rig -- the processor starts out in Real Mode. Real Mode provides no memory protection, no multitasking support, no code privilege levels -- no nothing. Any program has direct, unrestricted access to memory. Communication with hardware was provided by the BIOS via interrupt calls.

An interrupt does exactly what its name implies; it stops the CPU dead in its tracks. Programs would load a bitmap of an image into the frame buffer. It would then place a pointer to that memory in the low byte of the AX CPU register (known as AL), and the BIOS instruction to display it in the high byte (AH). It would then call BIOS interrupt 0x10h and the BIOS would take over. The CPU is no longer in control of your computer at this point.

The BIOS would then read the instruction in AH and passes the pointer in AL to the video hardware. The GPU would then copy the contents of the frame buffer into its own RAM and then releases control back to the BIOS, which then hands it back to the CPU. The CPU is now back in the driver's seat.

It's important to remember that all versions Windows 9x family were basically DOS applications. So when Win98 was showed its splash screen, the CPU was still in Real Mode, and it was still using BIOS interrupts to display it. The cute little animation at the bottom was just a palette cycling trick. There was no drawing happening there.

Now, when Windows loads, one of its first orders of business was to switch the CPU into 32-bit Protected mode. This basically kicked DOS out of memory and told the BIOS what it could go do with itself. Most of the functions that would have been handled by the BIOS are now replaced by the Windows HAL and Kernel. In a Windows world, applications talk to hardware via an API call, and that API call ran it through the display driver, which was a required component of the operating system.

Now (finally) here's where we move into your question. Windows did then (as it continues to do to this day) controlled video hardware via a display driver. If no driver was available, it defaulted back to the standard Windows driver, which used the framebuffer to do its drawing. The only difference being that the CPU is always in control via memory mapped I/O and the BIOS is not involved. If a driver was present, the driver would still use the MMIO, but to issue proprietary commands to the GPU, not bitmapped frames. The GPU has direct access to the memory and could operate in parallel with the CPU, including two-way communication through those I/O ranges.

Windows 98 did have drivers for the video hardware of its day, and could provide full-on 2D and 3D acceleration including OpenGL and DirectX. But it still needs a driver to communicate these things to the GPU and is unable to without it.

Drawing window controls (i.e. buttons, title bars, etc) were done through the Windows Graphics Device Interface (GDI), which was the main Windows API used for drawing screen elements. It has all kinds of functions, including shapes, pens, fill colors, and yes, bitmaps too. The GDI would translate those instructions into driver code. The driver (be it the GPU driver or the framebuffer driver) was in charge of getting those GDI instructions to the screen through whatever means it was programmed to do.

This is a lot to digest and it's just a brief overview of how data goes in and pixels come out. I hope it answers some of your questions.

  • This is an incredibly underrated answer that is well-written and technically 100% correct. Given your apparent low-level knowledge, I'm surprised to see that you haven't answered more Windows-related questions on Stack Overflow. – Cody Gray Jan 1 '20 at 11:05

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy