I struggled with GDI+ outside of .NET (C#), so going back to C is going to be.. interesting.. Do you have access to the GDI+ flattened function declarations for C? These should match the C++ interfaces except they take the "this" pointer as a first parameter. So theoretically you don't need any C-specific info on the usage of such functions.

wbahnassi wrote on 2025-04-19, 13:16:

I struggled with GDI+ outside of .NET (C#), so going back to C is going to be.. interesting..

So do you feel like someone first learning (an old) version of C# and .NET to get used to GDI+ first? Then try to "understand" the core that is developed in C?

Thanks

Yes I think that will make it much easier overall. The C# API is well documented too. So probably toy with it a few days then go to C and try to understand the pattern of mapping the code between the two.

wbahnassi wrote on 2025-04-19, 14:30:

Yes I think that will make it much easier overall. The C# API is well documented too. So probably toy with it a few days then go to C and try to understand the pattern of mapping the code between the two.

Thanks for your advice. I was wondering something else about C# and it's underlying assembling stage. I
want to try to understand a C# program by thinking through how it will be when it is turned into assembly by the compiler. Suppose I wanted to examine a sprite related method in C#, suppose I'm using monogame.

C# compiles to IL, not machine instructions like regular C/C++. You can restore the C# code from IL using reflector tools, and you will get back everything (classes, functions, even names unless obfuscation was used). The machine instruction representation of .NET assemblies reside in a special cache (GAC) which has the actual compilation of the program from IL to x64 (or whatever the target CPU is). So there's an extra hoop you need to take to find your exe to disassemble.

wbahnassi wrote on 2025-04-19, 17:49:

C# compiles to IL, not machine instructions like regular C/C++.

Instead of C# and the Monogame library what if I was using C++ and Direct 3d? In this case suppose the source code, in C++, draws a single pixel on the screen using the Direct 3d API. What might someone consider as they look through the source and think about it's translation into assembly language by the compiler? Does the component object model obfuscate a persons efforts to do this?

Any suggestions for thinking in assembly while one works with a c++ application? Is there a book about object oriented compilers and translating c++ source into assembly? I'm trying to address the aspects related to the architecture of the machine being programmed.

The whole point of using a higher level language like C++ is that you’re *not* thinking about how it translates to assembly instructions because you’re abstracting further away from the actual hardware and specific implementation details.

Any place that you really need performance then you would use inline assembly, otherwise for the most part you don’t give assembly a second thought.

C++ also isn’t doing anything magical - you can think of it as just C functions where the first argument is a pointer to the class instance (that’s largely what the compilers generate).

Ok. I don't fully understand but I hold beliefs about a beginner's first book about C or C++. I know that the example programs in these books are presented by experts such as Brian Kernighan or Bjarne Stroustrup. I believe that the process of becoming a programmer in C or C++ involves learning about a subject known as computer architecture. I also believe that the most practical way to gain experience with computer architecture is to study assembly code for a given architecture, say Intel x86. In fact the compiler for C and C++ translates the source into assembly code and the assembler program is bound to the C/C++ compiler. So, one can learn a great deal by analyzing C or C++ source, with their own thinking, into the assembler instructions that may follow.

Maybe look at Compiler Explorer https://godbolt.org/ then? You type/paste in your C/C++ code and then it shows you the assembly that different compilers generate.

https://learn.microsoft.com/en-us/windows/win … us-flatapi-flat

vgagame wrote on 2025-04-19, 19:56:

Instead of C# and the Monogame library what if I was using C++ and Direct 3d? In this case suppose the source code, in C++, draws a single pixel on the screen using the Direct 3d API. What might someone consider as they look through the source and think about it's translation into assembly language by the compiler? Does the component object model obfuscate a persons efforts to do this?

FYI not all compilers go through assembly to produce the final binary. MSVC spits out x86/x64 instructions directly without going via ASM. I believe many other up-to-date compilers do the same. Older compilers indeed produced ASM, but at some point they dropped that pass.

As for using COM, that won't be easily identifiable in disassembly. After a COM object is created, it's basically very similar to C++ classes (talking about D3D12's COM objects, which are simple and don't use all COM's complexities and features). In disassembly you'd see a function vtable embedded in the object's struct, which points to the implementations of each of the COM object's interface functions.

I began this thread asking about information about the GDI+ flat API. Thanks furan for the link. I have been trying to distill complex game libraries, graphics libraries, and APIs into their essential forms so I can understand how they work. Thanks Wahbanassi and Hornet for your replies. I see now that assembly code is useful but not necessary when learning to program. Assembly code can be useful for finding subtleties. However, without having to see it in assembly code one can think about the underlying computer organization when trying to understand a program written in C/C++. Wahbanassi, I feel like I should thank you for giving me the details about how COM would appear in assembly code form. I don't know what a function vtable is yet but I will eventually. For what comes to mind is for a large software system, like Direct3d or OpenGL, one would use their knowledge of computer architecture only on portions at a time. But before I ever do that I should start using the API itself to have an overview of the system as a whole.

That's a valid way to approach low-level programming.

I don't consider myself an assembly programmer, but I understand disassembly to validate that it's doing what I intend to. My experience came mainly from debugging crashes in my own programs.. especially if it's an optimized build, where the disassembly often doesn't map well back to the high-level code it originaly came from. At that point, you have no choice but to chase values in registers and look at the memory to locate your data structures and understand why the program reached the point it crashed at... fun times!
My first job at EA had me debug a crash on PS2 that turned out to be bad code-gen from the SN compiler itself. I got a raise for catching that bug 🤣