There is OpenGL but are there other options? One thing that comes to my mind is to make a Win App that uses GDI. But is there anything else?

In the end, you have to take what the OS offers (as long as you don't intend to share your program with some kind of boot code as well :D ) so the questions shouldn't be what options you have using language X, the question should be what your target platform offers and how you could interact with it. I don't know of any way these days, to get Windows for example to let your code access any of the graphics buffers directly, you always have to ask it for such a thing you are allowed to write to regardless if you are using GDI, OpenGL or DirectX (I don't know if Mesa is available for Windows). It is hard to nearly impossible to bypass the OS Window system at least for security reasons.

I guess your best bet would be to go for Linux and have your own Window System similar to XWindow or whatever if you really want to take full control over it, but even there I guess you to provide it with some kind of kernel mode to be able to access graphics hardware directly

In the end, you have to take what the OS offers

At this point it`s just a learning experience (my goal is not to come up with something that people are going to install on their computers). I will choose whatever allows me to display graphics. I`m not keen about using OpenGL (at all, regardless if its Linux or Windows), so if Windows 10 is not going to cooperate I could use Windows 7 with a virtual machine.

Same “security brakdown” for Windows since NT. I don't know if Windows 98 allowed to directly address the video buffer ( I guess so) but on any modern machine your hands are bound by real mode CPUs

Decades ago there were systems to emulate what old hardware did, with video memory and paged access, and with older VESA interfaces for access to memory and a frame buffer.

Security models on every system have changed since then, direct hardware access is out for almost anything unless you are developing drivers.

Rendering hardware has changed, too, and simple linear buffers vanished at the turn of the century.

You might be able to find some way to emulate it supported by the OS, but like above, it is whatever the OS grants you. Either that or write a device driver, which requires knowledge about the actual hardware interfaces.

Calin said:
I`m not keen about using OpenGL (at all, regardless if its Linux or Windows), so if Windows 10 is not going to cooperate I could use Windows 7 with a virtual machine.

If you want the old school way of having a bitmap and draw everything in software to that, you can still do this without a draw back of current day OS abstraction in practice.

You only need to have a tiny OS / gfx API section, which uploads your bitmap as texture to GPU and displays it. Not more work than it was back then using mode 13, or messing with hardware sprites / raster interrupts.
And you can do this with OpenGL too, even if you know nothing else about it. Copy pasting some basic tutorial is enough.

It's always important to minimize dependencies (on API, some framework or library), but it's not helpful or possible to avoid it completely. It seems you intend to avoid dependencies on third party software (APIs, libraries or frameworks…). Well, you can do this, but then you get dependencies on OS and hardware instead, which is no better.
Usually the best way to deal with this is abstraction. E.g. having your own render API with backends for DirectX and openGL. If MS goes bankrupt and Khronos gets stuck in discussion, you would just add another backend for whatever API comes up in the future.

I believe you can also use DirectX from C. I have never done it and I think you have to do some extra stuff with the COM interface but I remember reading it's doable. If you can use it from C, you should be able to use it from ASM. You just have to know the calling convention.

I had to help a friend with an x64 ASM assignment a few years back and I had to look this stuff up. At that time it was hard to find the info on it. I think I used something I found on gamasutra so you can search there if all else fails. In any case it's actually not hard at all. I think the first 4 parameters are passed in registers and the rest on the stack. There are some alignment requirements but that's about it.

If you want to go really hard core you can simply write to memory and dump that to the screen. In the old days cards used to just be a special chunk of memory that was mapped to the screen. You could do graphics by writing to an array. I had to do a whole low level graphics package like this: line drawing, polygon scan conversion, seed fill …. everything. Look up Bresenham's algorithm. It's useful for a lot of this stuff if you want to go that route

thanks for feedback everyone

@gnollrunner

In any case it's actually not hard at all

You sound as if you`re talking about splitting sunflower seeds and eating the kernels.

@JoeJ

You only need to have a tiny OS

I`d skip over writing an OS if I could

Calin said:
I`d skip over writing an OS if I could

I did not mean you should do your own OS : )

What i mean is: If you want to write a full game in ASM (which restricts you to something like PacMan in practice), then you still need a bit of C / C++ / etc. to use Direct X.

Recently i was surprised when i have learned Direct X12 seems to require C++. I would have assumed C is enough, like for any other API i know, but seems not. Older DirectX versions should work with C, and so ASM as well.

But why take that pain and frustration? What's your motivation here?

[edit]