File IO and stdlib stuff has been covered already
nocash wrote:Oh, okay, I guess I have missed the point. I was thinking about asm & network & os calls & GUI functions as separate issues (and especially missed the part about network being needed to access GUI functions).
If I got it right now: Linux kernel doesn't have a GUI at all, and one cannot access the GUI via "call" opcodes or the like.
Instead, one must access the GUI via network send/sendto functions?
That is unfamilar from a dos/windows point of view. And more so from a nes/snes point of view ; )
Sort of. There are similar splits between the kernel, window manager, widgets, and rendering interface on windows, but it isn't quite as obvious as the programming interfaces across them are a bit more consistent, and there aren't generally a wide variety of options. A rough breakdown of what most windows programs link to, and the closest analog for linux:
- kernel32.dll -- Basic system services, file IO, etc. Provides the core of the Win32 API to programs, via syscalls down to NTDLL
Linux equivalent is glibc (providing the wrappers to do the actual system calls), which poke the kernel to do the work
- user32.dll -- Window management, gui message handling, user interface widgets, IO glue. Provides the basic win32 window and control classes.
Linux equivalent is a combination of the X display server, destop environment/window manager, and widget libraries like Xt, Xaw, gtk, and Motif. Programs communicate with the X server via a socket, which could be a real network socket, or a local pipe. Generally people link against Xlib, which provides a C language interface for managing that connection and exposing the message types. Widget libraries are a layer in between, that provide various widgets and controls, in a particular style.
- gdi32.dll -- GUI rendering and painting
Linux deals with this inside the X display server, mostly via requests similar to a WM_PAINT message.
- comdlg32.dll/comctl32.dll -- Fancier looking widgets and common dialogs. Where most of the 3D-look bits of the windows UI come from.
Linux equivalent would be the widget libraries, where the code is providing the equivalent of the new message types and the window procedure
Explorer and window manager interface
On a linux system, running X or a compatible display server (the usual approach to guis that play nicely with others), programs communicate with an X display server. This is another process, that usually encompasses the display drivers, and provides controlled access to the screen and user interface devices via a well defined protocol suitable for use over a network. There are a bunch of extensions to make this process more efficient when running locally. It only provides basic window tests and messaging -- all painting and interface policy is up to the programs themselves.
There is another process usually running, the Window Manager, which provides the actual desktop interface. In windows, this would be what handles most of the non-client area. Programs communicate with it via X messages, sent through the display server. It generally provides title bars, close buttons, task bars, etc. A lot of them these days come as part of a larger desktop environment, packaging the window manager up with a number of expected utilities, like file managers, calculators, and such.
In windows, when you create your toplevel window, it distinguishes between the client area and non-client area, depending on your window style, and the system provides various bits in the non-client area. On Linux, when you create a toplevel window, the window manager gets a message about it, and it creates its own windows to provide those features. Message routing is slightly different, on X you would generally only see messages for your client window, on Windows, you would see messages related to the non-client area, but DefWndProc takes care of passing them on for you.
Makes me wonder if anybody has ever implemented a compact GUI Hello World program for Linux (asm or not)?
Would be interesting if there's a source code package with bare minimum stuff for Hello World.
If it takes 10K lines in asm, then it would probably also take 5K-20K lines in C, right?
The usual thing here would be Xlib only, or Xlib+Xt only minimalist programs. The C versions would probably be smaller in terms of code, given the conciseness of passing arguments around. Talking to the X server via raw Xlib calls is a bit lower level than raw Win32 without MFC, and punts a lot more on to you. Xlib+Xt is the closest equivalent to that, providing basic widgets like menu bars, scroll bars, and buttons.
If I should ever learn linux coding, I would want to things: Using my own source code (without including third party code), and, especially using 100% asm code (without including third party C code).
Else it wouldn't be fun to say that I had written the program in asm (but didn't have written most of it myself, because it does mainly consist of C written by other people).
This depends on exactly what you mean by third party code, and where you draw the line. You could talk directly to NTDLL on windows, and bypass CreateFile and friends, but I doubt you go down that route.
If you're aiming at the linux equivalent of dealing with raw Win32, including the standard controls (static text, buttons, menus, scrollbars, maybe the common file dialog), that would be writing against a subset of glibc (for system calls), Xlib (for the PeekMessage, CreateWindow equivalents), and Xt (for the basic widgets)
If you're aiming even lower than that, and issuing the syscalls directly from assembly, that will of course differ between x86, arm, ppc and amd64. You could speak directly to the server via socket related syscalls, but you will basically be reimplementing Xlib. It does not do that much in the way of fancy buffer management or anything.