Programming GUI in assembly / machine code

[chrstrbrts]

Hello,

How would you program a GUI application in assembly / machine?

Let's say something really simple:

I want to make a window pop up that has an X box in the corner that when clicked makes the window disappear and terminates the program.

In Java, I would just make a new JFrame or something. But the code in high level Java would map to atomic operation codes for the processor.

I know that they are processor dependent, but in general, what are those op codes?

Also, in general, how do you code event handling in assembly / machine?

Do you tell the processor to wait for a mouse interrupt signal? Then, query the location of the click and if the click occurred where the X box is currently located on the screen and then tell the screen to redraw itself without the window?

Would that work?

Thanks.

 

[Markbnj]

Literally speaking, you could write assembly language instructions that correspond to all the operations you would code in the higher level language. So you could write GUI applications in assembly language, but it would be like trying to build a car from iron ore.

 

[Ken g6]

IIRC, Steve Gibson claimed to write GUI apps in assembly language. Whether he actually did or not is a matter of debate. One benefit he claimed from doing so was smaller application size; but he was then found to have been using UPX.

 

[Merad]

It isn't that different from GUI programming in C with the raw Win32 API (or whatever linux API), just more painful. You're just going to be calling the library functions from assembly.

http://www.oopweb.com/Assembly/Documents/Win32ASM/Volume/winbasic.htm

In Java, I would just make a new JFrame or something. But the code in high level Java would map to atomic operation codes for the processor.

I know that they are processor dependent, but in general, what are those op codes?

Also, in general, how do you code event handling in assembly / machine?

1. No, Java source code complies to Java bytecode. The Java Virtual Machine (JVM) executes the bytecode.

2. http://programminggroundup.blogspot.com/2007/01/appendix-b-common-x86-instructions.html

3. You use the OS facilities like the Win32 event loop.

If you're wanting to know how to do all of this from scratch without the help of an operating system, that's an extremely non-trivial topic and I'd suggest that you google it.

 

[Cogman]

Hello,

How would you program a GUI application in assembly / machine?

Let's say something really simple:

I want to make a window pop up that has an X box in the corner that when clicked makes the window disappear and terminates the program.

In Java, I would just make a new JFrame or something. But the code in high level Java would map to atomic operation codes for the processor.

I know that they are processor dependent, but in general, what are those op codes?

Also, in general, how do you code event handling in assembly / machine?

Do you tell the processor to wait for a mouse interrupt signal? Then, query the location of the click and if the click occurred where the X box is currently located on the screen and then tell the screen to redraw itself without the window?

Would that work?

Thanks.

I'm just going to say it, you really need to learn to walk before you can run here. You don't appear to have even a basic understanding about how operating systems, GPUs, or CPUs operate, yet you are asking "Hey, what is the code to do this complex thing in at a very low level?"

Before even broaching this subject, you should learn

1. How to program in a high level language (Java/python/C#)
2. How to program guis in a high level language
3. How to program in a low level language (C/C++)
4. How to program guis in a low level language
5. How to program operating system specific guis in a low level language
6. How to program in assembly
7. How to to make system calls to the OS in assembly.
8. How to program guis using assembly

You are asking questions about how to do 8 without having any understanding of 1->7. You really REALLY need to know 1->7 before you can begin to broach the subject of 8. Trying to just learn 8 before 1->7 is never going to work, there are simply way too many concepts you need to have down.

But if you really want to go down this path. I would suggest reading

http://www.plantation-productions.com/Webster/www.artofasm.com/Windows/HTML/AoATOC.html
www.winprog.org/tutorial/
http://win32assembly.programminghorizon.com/tutorials.html

 

[chrstrbrts]

I'm just going to say it, you really need to learn to walk before you can run here. You don't appear to have even a basic understanding about how operating systems, GPUs, or CPUs operate, yet you are asking "Hey, what is the code to do this complex thing in at a very low level?"

Before even broaching this subject, you should learn

1. How to program in a high level language (Java/python/C#)
2. How to program guis in a high level language
3. How to program in a low level language (C/C++)
4. How to program guis in a low level language
5. How to program operating system specific guis in a low level language
6. How to program in assembly
7. How to to make system calls to the OS in assembly.
8. How to program guis using assembly

You are asking questions about how to do 8 without having any understanding of 1->7. You really REALLY need to know 1->7 before you can begin to broach the subject of 8. Trying to just learn 8 before 1->7 is never going to work, there are simply way too many concepts you need to have down.

But if you really want to go down this path. I would suggest reading

http://www.plantation-productions.com/Webster/www.artofasm.com/Windows/HTML/AoATOC.html
www.winprog.org/tutorial/
http://win32assembly.programminghorizon.com/tutorials.html

Oh, I totally agree. I didn't ask my original question because I'm planning on programming a GUI in assembly any time soon; I asked out of sheer curiosity.

I'm still a baby. I've decided on Java for my first language, and while I have the syntax down, I'm still learning the finer points of the Java development environment.

Anyway, what I'm totally mesmerized with is the software / hardware interface. The idea that you can program electronics fascinates me.

Unfortunately, the levels of software abstraction through me off a bit. I understand the idea of abstracting away the interface with hardware to make things easier for developers, but I feel like if you don't dig into the abstraction layers and ask questions you'll never really understand how the machine works.

Incidentally, to create a window in Java would take about 10 lines of code total, including the import statements.

But how many opcodes would that translate into? 50? 100? 1,000? 10,000?

Thanks.

 

[Cogman]

Oh, I totally agree. I didn't ask my original question because I'm planning on programming a GUI in assembly any time soon; I asked out of sheer curiosity.

I'm still a baby. I've decided on Java for my first language, and while I have the syntax down, I'm still learning the finer points of the Java development environment.

Anyway, what I'm totally mesmerized with is the software / hardware interface. The idea that you can program electronics fascinates me.

Unfortunately, the levels of software abstraction through me off a bit. I understand the idea of abstracting away the interface with hardware to make things easier for developers, but I feel like if you don't dig into the abstraction layers and ask questions you'll never really understand how the machine works.

It is abstractions all the way down. To be a good developer you need to learn how to work and shift abstractions, nobody holds the entire thing in their head. I agree that any developer worth their salt should have at least cursory knowledge about the low level system architecture, but not as a first step.

Incidentally, to create a window in Java would take about 10 lines of code total, including the import statements.

But how many opcodes would that translate into? 50? 100? 1,000? 10,000?

Thanks.

This is unanswerable as it will depend completely on operating system, platform, java version, how long the JVM has been running, if the method has been executed before or not, etc (And no, I'm not joking, all of those things are going to change the number of instructions used).

It is hard to even give a good answer estimation on how many instructions are used. For example, what happens if the GC fires while you are creating the window? Do you count that in the instruction count? What if the one of the several optimizers/deoptimizers runs for the method? Do you count those instructions? Do you count the optimized instructions or the de optimized instructions? Do you count the extra stuff the JIT is doing in the background? What about the video card drivers? How many instructions are those doing?

The instruction count could easily be anywhere from 1000 -> 1000000

 

[Markbnj]

It is abstractions all the way down.

Turtles. It's supposed to be turtles.

 

[chrstrbrts]

It is abstractions all the way down. To be a good developer you need to learn how to work and shift abstractions, nobody holds the entire thing in their head. I agree that any developer worth their salt should have at least cursory knowledge about the low level system architecture, but not as a first step.

Is there anyone out there who knows the whole shebang from transistors to keyboard?

Is there anyone who can build an entire computer from scratch, write an OS, write drivers, write advanced APIs, etc?

The instruction count could easily be anywhere from 1000 -> 1000000

Wow. That broad of a range?

 

[Merad]

Is there anyone out there who knows the whole shebang from transistors to keyboard?

Is there anyone who can build an entire computer from scratch, write an OS, write drivers, write advanced APIs, etc?

No. You're talking about a project that would require expert level knowledge in dozens of fields. The hardware of a modern computer is incredibly complex.

For example, one of my professors in school worked for IBM on the keyboard of the original Thinkpad. He spent several years working on the firmware for the keyboard controller that interfaced with the keyboard hardware and communicated its state to the main CPU. A project that took years results in roughly 1/1000th of what you need for a full computer.

Probably the best example of genius I've seen is Temple OS. The guy who made it is certifiable, but also appears to be a freakin' genius when it comes to OS/driver type programming. But even he is not touching the hardware, and you'll notice that his OS is extremely primitive compared to anything remotely modern.

Wow. That broad of a range?

I would say that there's a 99% chance that 1000 opcodes is too low, and a very good chance that a million is too low as well. The JVM will be making multiple calls into the OS to allocate memory, create the window, display it, etc. Then you have the code of the JVM itself. And as has already been pointed out, the state of the JVM can drastically affect what occurs.

 

[Exophase]

It isn't that different from GUI programming in C with the raw Win32 API (or whatever linux API), just more painful. You're just going to be calling the library functions from assembly.

The real thing that makes calling C APIs from assembly annoying is knowing where the offsets in structs are. Maybe you'll find some tool that automatically generates them from a header file, but I've never found such a thing (or bothered to write my own, I just make some C program that manually prints them out)

 

[Cogman]

No. You're talking about a project that would require expert level knowledge in dozens of fields. The hardware of a modern computer is incredibly complex.

For example, one of my professors in school worked for IBM on the keyboard of the original Thinkpad. He spent several years working on the firmware for the keyboard controller that interfaced with the keyboard hardware and communicated its state to the main CPU. A project that took years results in roughly 1/1000th of what you need for a full computer.

Probably the best example of genius I've seen is Temple OS. The guy who made it is certifiable, but also appears to be a freakin' genius when it comes to OS/driver type programming. But even he is not touching the hardware, and you'll notice that his OS is extremely primitive compared to anything remotely modern.

Yup. Nobody knows everything about the computer. It is specialization upon specialization.

I would say that there's a 99% chance that 1000 opcodes is too low, and a very good chance that a million is too low as well. The JVM will be making multiple calls into the OS to allocate memory, create the window, display it, etc. Then you have the code of the JVM itself. And as has already been pointed out, the state of the JVM can drastically affect what occurs.

Good point.

Mostly I was trying to stress the high variability on how many instructions it takes. It is pretty much unknowable and frankly a detail that really doesn't matter.

 

[GarfieldtheCat]

Oh, I totally agree. I didn't ask my original question because I'm planning on programming a GUI in assembly any time soon; I asked out of sheer curiosity.

I'm still a baby. I've decided on Java for my first language, and while I have the syntax down, I'm still learning the finer points of the Java development environment.

Anyway, what I'm totally mesmerized with is the software / hardware interface. The idea that you can program electronics fascinates me.

Unfortunately, the levels of software abstraction through me off a bit. I understand the idea of abstracting away the interface with hardware to make things easier for developers, but I feel like if you don't dig into the abstraction layers and ask questions you'll never really understand how the machine works.

Incidentally, to create a window in Java would take about 10 lines of code total, including the import statements.

But how many opcodes would that translate into? 50? 100? 1,000? 10,000?

Thanks.

I would go out and buy Charles Petzold's Code and read it.

It is a great easy intro to how computers work.

 

[SteveGrabowski]

Anyway, what I'm totally mesmerized with is the software / hardware interface. The idea that you can program electronics fascinates me.

You might find this video course interesting then.

http://webcast.berkeley.edu/playlist#c,d,Computer_Science,-XXv-cvA_iC_nP-PWFi66murdT_-Nqi1

 

[velis]

I don't think such a feat is even achievable any more:
In the old days we had display adapters that basically composed a very low-resolution picture from a directly-accessible memory buffer. That made it possible to implement the actual drawing routines (using assembly or a higher level language).
Nowadays I suppose you'd have to use either VESA calls (video BIOS functions) or direct gfx card calls (there's usually no public API for that), but I don't think directly manipulating video buffers is even an option any more.

That's only for actually drawing the window. Then you have to make the mouse pointer move, register mouse clicks, process fonts (a MUCH more demanding job than drawing lines / rectangles), etc.

Ultimately, there isn't THAT much needed to actually be able do do this. there are OSs that can stuff a little GUI drawing and much more on little more than 1 MB.

http://kolibrios.org/en/releases (see a little older releases, they get really small )

 

[chrstrbrts]

Thanks, everyone.