Linux / Windows GUI application with assembly
in [ASM]
|
Prev: TMA Assembler?
Next: pshufb
From: Frank Kotler on 6 Nov 2006 15:05 Betov wrote: > "KiLVaiDeN" <kilvaiden(a)gmail.com> ?crivait news:1162808259.331364.26920 > @k70g2000cwa.googlegroups.com: > > >>So basically guys, does it mean that there is no simple way of creating >>cross platform assembly GUI application, while taking advantage of the >>assembly low-level power ? I fear that it may be worse than that. I suspect that even using C or some HLL, a cross-platform GUI app isn't going to be "simple". I suspect that any cross-platform GUI app you find is going to depend heavily on "powerful" (slow and bloated) helper libraries. Inevitable, since Linux does GUI in quite a different way. Graphics are *not* part of the kernel, but an "app" that runs in the OS like any other. Worse, it's a "server", and as a "client", your app does graphics by writing requests to a socket, and the server puts the pixels where you said. This is normally wrapped by Xlib, and or other helper libraries. This all *can* apparently be wrapped to give an interface consistent with the Windows API, but the "simple" way to do it hasn't been found yet. As I recall, when I installed gtk(+ ?), I had to install four or five other libraries, in the correct order, first. I'm not familiar with wxWidgets - didn't it used to be called wxWindows? I think I downloaded that once - 7 or 8 Megs, IIRC. My reaction to this stuff is, "That looks like a truck tire. I wanted a racing bike tire. I'm going to have to reinvent the wheel!" > There has never been any "simple way" for doing any > pioneer work, unfortunately, K. I'd wish there could > be some, but... > > :)) Agreed. KiLVaiDeN may have some advantage on us, though. He doesn't seem to be as repelled by high level languages as you and I are. :) > As you might know, there has been several long years > of hard works, done by many pioneers of Win32Asm, > before Applications could have been written in Asm, > under Win32, and the Linux Asm Stuff is still in the > very same state, it was for Windows... 15 years ago. > > :( It's true that Linux assembly hasn't progressed very far. GUI assembly, in particular. > Linux is definitively NOT any area for Assembly. I only partially agree with this. Assembly is not the "Unix way". The idea is that code ought to be available to *everyone* - no one excluded - even the folks who are not running x86s. It is "selfish" to write assembly for Linux or any flavor of Unix. The other side of this coin is, "Why should the majority - running x86s - be deprived of the inimitable benefits of programs written in assembly language?" "... Saw a sign there, said "no trespassin'" but on the other side, it didn't say nothing. That side was made for you and me!" But I'd agree that Linux is not a great area for graphics. I know, I know, Linux is not dos on steroids, but "like dos" there's no inherent support for graphics. To do even something as simple as colored text, you've got to jump through hoops. In Linux, the hoops are different shapes, and there's more of 'em. > Would > it be one, even with a little bit more problems, what > you mean to do would exist since ages, given the number > of volunteers around Linux, and given the numbers of > attempts, we have seen passing and going to... the trash > bin. Where's this trash bin? Maybe something can be dusted off and reused! > Not to discourage you, but, if you persist on this plan, > be prepared for _years_ of pioneer's work without any > guaranty of success, and of "royale indiff?rence", in > case it would go to an end. I'm afraid you may be right, but it may not be that bad... What's the situation in Windows? You can't do squat without calling a library, right? You can't even ExitProcess without linking in kernel32.dll! (and you haven't even got the source to it!!!) I imagine to do a "GUI app", you'll want several more dlls beyond that, right? Suppose we extend the same courtesy to Linux? Call all the libraries you want! (if you're running Xwindows, they're probably sitting in memory anyway - there's *some* overhead to using them, but not much) (we're not talking about static linking here - dunno where you got the idea that Linux does this - all dynamic libraries, just like Windows) Now the task is a little more tractible, if still not "simple". I prefer to minimize the calls to "black boxes", but if KiLVaiDeN is okay with doing that, in the interest of portability, I think a Linux/Windows GUI app is possible. The examples I've seen (some in the linux- win-32-nasm-users groups on !Yahoo!) are rudimentary, but I don't see any "barrier" to extending them to do whatever you want. (but beware the "invisible sheild"!) Whether there's any "advantage" to using assembly at this point remains to be seen. I suspect, "not much". If your "app" consists of a series of library calls, there isn't much room for improvement in the calling code. OTOH, if you've got some sort of "invoke" (and/or "sys_call") macro, it's just as easy to do a series of library calls in asm as any other language, so what have you got to lose? :) Best, Frank
From: Frank Kotler on 6 Nov 2006 16:01 KiLVaiDeN wrote: .... > As we can see, there is no way for coding GUI assembly application with > Linux. Yes, you can do it with GTK, but it's not what I'd call a "real" > way of doing it; Using a 3rd party library is different than using the > base windowing system, as it's possible under Win32. When we'll be able > to use Xlib from Assembly, we'd have made a great advance in Assembly > programming under Linux for GUI applications; Not yet. So Rene was > right, once again, about his assumption. Whoop!!! Man, you sure quack like a fanboy! Best, Frank (pardon the ugly RosAsm-like syntax... something I was sharing with Wannabee) ; rudimentary "hello world" for Xwindows ; nasm -f elf -O999 x1.asm ; add the "-g" switch for debugging info - good luck! ; ; sorry 'bout this one... ; ld -s -o x1 x1.o -I/lib/ld-linux.so.2 -L/usr/X11R6/lib -lX11 ; ; if you want it small: ; strip -R .comment x1 ; ; after all that, we still have to tell ld where the fun begins: global _start ; inform Nasm that ld knows where to find this stuff (we hope!) extern XOpenDisplay extern XDefaultRootWindow extern XCreateSimpleWindow extern XNextEvent extern XDestroyWindow extern XCloseDisplay extern XMapRaised extern XSelectInput extern XStoreName extern XCreateGC extern XFreeGC extern XDrawImageString extern XSetForeground extern XSetBackground ; we'll be needing lots more of these... KeyPressMask equ 1 ; mask for XSelectInput KeyPress equ 2 ; the "type" of event (offset 0 in "glob of bytes") ExposeMask equ 1 << 15 ExposeEvent equ 12 event_size equ 20h ; ??? max size of several different structs ; oops, I mean "globs of bytes" :), in dwords ; I *think* the biggest one is 15 dwords(???) ;------------------------------------------- ; a rudimentary "RosAsm compatibility" macro. ; we need a space after this for it to work! ; Note that this depends on undocumented Nasm syntax!!! %idefine D$ dword & %idefine W$ word & %idefine B$ byte & ;------------------------------------------- ;------------------------------------------ section .data StringOpenFailed db "Can't Open X display!", 10 StringOpenFailed_len equ $ - StringOpenFailed caption db 'No Caption', 0 string db ' Merry X, World! ' string_len equ $ - string ;----------------------------------------- ;----------------------------------------- section .bss Display resd 1 Window resd 1 GC resd 1 ; this is a place for XNextEvent to put a "glob of bytes". event resd event_size ;------------------------------------- ;------------------------------------- section .text _start: ; let the ritual begin. ; nop ; parking place for gdb ; open a connection to the server. ; pushing 0 uses the "DISPLAY" environment variable ; or defaults to local machine. push 0 call XOpenDisplay add esp, 4 or eax, eax je OpenFailed mov D$ Display, eax push D$ Display call XDefaultRootWindow add esp, 4 ; error? push 0 ; background colour push 0 ; border colour push 0 ; border width push 300 ; height push 400 ; width push 50 ; top co-ord push 50 ; left co-ord push eax ; XDefaultRootWindow, from above push D$ Display ; display handle call XCreateSimpleWindow add esp, 36 ; C clean-up parameters stuff or eax, eax je CreateFailed mov D$ Window, eax ; this is one Windows doesn't do. if we don't specify ; what events (messages) we want to receive, we don't get any. push KeyPressMask | ExposeMask ; "or" this with other events to recv! ; don't forget to handle 'em! push D$ Window push D$ Display call XSelectInput add esp, 12 ; error? ; spec said "No Caption", so that's what we do :) push caption push D$ Window push D$ Display call XStoreName add esp, 12 ; error? ; make our window visible. push D$ Window push D$ Display call XMapRaised add esp, 8 ; error? push 0 ; values? push 0 ; valuemask? push D$ Window push D$ Display call XCreateGC add esp, 16 ;error? mov D$ GC, eax ; Mmmm, looks like 16-bit color, 5-6-5, on my machine. ; Bet we can't count on it! ; push 65535 ; white push 1111100000000000b ; red push D$ GC push D$ Display call XSetForeground add esp, 12 ; error? ; push 0 ; black push 0000011111100000b ; green push D$ GC push D$ Display call XSetBackground add esp, 12 ; error? ; call drawscreen Eventloop: push event push D$ Display call XNextEvent add esp, 8 ; error? cmp D$ event, ExposeEvent jnz not_expose call drawscreen jmp Eventloop not_expose: cmp D$ event, KeyPress jne Eventloop ; exit gracefully if key pressed push D$ GC push D$ Display call XFreeGC add esp, 8 push D$ Window push D$ Display call XDestroyWindow add esp, 8 CreateFailed: push D$ Display call XCloseDisplay add esp, 4 jmp Terminate OpenFailed: mov eax, 4 ; __NR_write mov ebx, 2 ; stderr mov ecx, StringOpenFailed ; buffer mov edx, StringOpenFailed_len ; count int 80h Terminate: mov eax, 1 ; function (sys_exit) xor ebx, ebx ; exit code int 80h ; make Linux system call ;------------------------------------------- ;------------------------------------------- drawscreen: push string_len push string push 140 ; y pos push 155 ; x pos push D$ GC push D$ Window push D$ Display call XDrawImageString add esp, 28 ; error? ret ;---------------------------------------------
From: Betov on 6 Nov 2006 17:03 Frank Kotler <fbkotler(a)comcast.net> ?crivait news:OLadncLld_AdC9LYnZ2dnUVZ_vadnZ2d(a)comcast.com: >> Would >> it be one, even with a little bit more problems, what >> you mean to do would exist since ages, given the number >> of volunteers around Linux, and given the numbers of >> attempts, we have seen passing and going to... the trash >> bin. > > Where's this trash bin? Maybe something can be dusted off and reused! Oh... when writing this, i was thinking of a bright example: A guy who was called "Basic" (a real _pest_) who developed quite good examples of GTK with FASM, years ago... had it any follow-up?... Zero. I even doubt his Demos could still be somewhere. >> Not to discourage you, but, if you persist on this plan, >> be prepared for _years_ of pioneer's work without any >> guaranty of success, and of "royale indiff?rence", in >> case it would go to an end. > > I'm afraid you may be right, but it may not be that bad... > > What's the situation in Windows? You can't do squat without calling a > library, right? You can't even ExitProcess without linking in > kernel32.dll! (and you haven't even got the source to it!!!) I imagine > to do a "GUI app", you'll want several more dlls beyond that, right? > Suppose we extend the same courtesy to Linux? Call all the libraries > you want! (if you're running Xwindows, they're probably sitting in > memory anyway - there's *some* overhead to using them, but not much) > (we're not talking about static linking here - dunno where you got the > idea that Linux does this - all dynamic libraries, just like Windows) Maybe, but the real facts is that, whatever you would like to experiment, you will always get a message saying that "something" in not installed. And if you try to understand... what... > Now the task is a little more tractible, if still not "simple". I > prefer to minimize the calls to "black boxes", but if KiLVaiDeN is > okay with doing that, in the interest of portability, I think a > Linux/Windows GUI app is possible. I did not said it was _impossible_... It is just honest to not let him take on illusions, and being later disapointed by the amount of hell work. > The examples I've seen (some in the > linux- win-32-nasm-users groups on !Yahoo!) are rudimentary, but I > don't see any "barrier" to extending them to do whatever you want. > (but beware the "invisible sheild"!) Whether there's any "advantage" > to using assembly at this point remains to be seen. Which is the problem. Don't you think that, if it was really that easy, it would already exist, considering the very _HUGE_ number of Linux volunteers compared to the number of Win32Asm ones? > I suspect, "not > much". If your "app" consists of a series of library calls, there > isn't much room for improvement in the calling code. OTOH, if you've > got some sort of "invoke" (and/or "sys_call") macro, it's just as easy > to do a series of library calls in asm as any other language, so what > have you got to lose? :) For me the very first "improvement" is that i can write Applications, whereas i will always and absolutely refuse to write any in C: "Better dead than C". Reversing your argument, if we can do it in Assembly, there is no reason for doing it in a more difficult Language, that has only inconvenients, and which "philosophia" is radicaly unacceptable, in the same way that Nazism, Bush or Polpot are unacceptable for a chinese paralytic Anarchist. Betov. < http://rosasm.org >
From: Charles A. Crayne on 6 Nov 2006 19:36 On 6 Nov 2006 07:05:00 -0800 "KiLVaiDeN" <kilvaiden(a)gmail.com> wrote: :There must be a way to hack Xorg, the same way the Win32 API is :"hacked" by assembly programs. I say "hacking", because like the Win32 :API, the Xorg API is not supposed to be coded in assembly from a :starter. It has similar calls than those of the Win32 API, so I think :it wouldn't be totally out of mind to think of "hacking" it with :assembly, by declaring clever includes, like it's done in Win32 ASM :nowadays.. Actually, I did this a couple of years ago, and if you are interested, you can download the source files in your choice of fasm and/or nasm format, from my webpage: http://www.pacificsites.com/~ccrayne/charles.html Please feel free to email me if you have any questions. -- Chuck
From: sevag.krikorian@gmail.com on 6 Nov 2006 20:00
On Nov 6, 5:17 am, "KiLVaiDeN" <kilvai...(a)gmail.com> wrote: > So basically guys, does it mean that there is no simple way of creating > cross platform assembly GUI application, while taking advantage of the > assembly low-level power ? > > I am looking into possibilities to do this, in a mix of high-level and > assembly, which would be the best way to go I guess for such a project, > but it seems a little bit complicated nonetheless. > > I also thought of doing it in full assembly, using an OpenGL wrapper, > to make the interface of the program; But this too would require a lot > of work..... To implement all the functionalities of a usual GUI > interface... > > Oh well ! > Thanks for the answers :) > > Cheers > K I did a base case of this some time back to test the theory in HLA. It potentially works: At the basic level, you create a blank window using the OS calls, then custom draw everything using function calls and conditional assembly. The demo I wrote worked in Windows/Linux with X, you can open a basic window with a close button, draw some colored text and lines, track mouse movement, mouse clicks, window movement, sizing and that was about it. I can tell you that it is tons of work! I haven't even tried to tackle menus and lists, scrollbars, etc yet and probably will not continue as it is too much work for one person to do. I think another thing to look at (aside from those already mentioned here) would be OpenGL with some cross-platform libraries written for it. |