Linux / Windows GUI application with assembly
in [ASM]
|
Prev: TMA Assembler?
Next: pshufb
From: Frank Kotler on 6 Nov 2006 20:14 Herbert Kleebauer wrote: > KiLVaiDeN wrote: > > >>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. > > > Xlib also is nothing but a "3rd party library". But you can directly > connect to the Xserver without using Xlib. A few weeks ago Linux > assembly code was posted here to open a Window. Now you can be the pioneer > and find out the rest (output text and graphics, get mouse and keyboard events). We have mouse and keyboard events. No text or graphics yet - first need to create a gc... and I don't know what the "minimum" we can do is. While progress is very slow, I *do* pick away at that once in a while. I'll try to post a "progress report" soon... (I don't really expect this to lead to anything useful, but it *can* be done without *any* libraries at all. Try *that* with your "base windowing system"! ... no libraries in *my* code, that is - at the other end of the connection is a "C-monster", of course. :) Best, Frank
From: Chewy509 on 6 Nov 2006 22:43 KiLVaiDeN wrote: > Hello group, > > To make a GUI application multi-platform enabled, what library would > you chose for the design ? > > I suspect GTK is the best solution, since GTK apps exist for both > platforms, but I'm still wondering if maybe I've missed a library that > is worth looking at, from the assembly point of view. > > I want to code my GUI application in assembly, and be able to compile > the source for both platforms without change ( or with MINIMAL change ) > on both platforms. > > For the moment, my choice is : FASM + GTK.. But I'm unsure about how > well this would work in a windows environment. Pretty much GTK+2, QT or wxWidgets. I've personally had success with GTK on Linux (AMD64), FreeBSD (AMD64) and Windows XP x64. (Haven't played with QT though, since I don't have it installed). I will admit most of the code is more proof of concept than a serious application... (eg. getting the calling convention correct). The problem being that they are all C/C++ based (GTK is C, QT/wxWidgets is C++), which means jumping through a few hoops with the calling convention, but all in all not that difficult, with GTK being the easiest as it's still largely a C based library (and not C++). Just be aware, that you will still wrapping code around most OS I/O functions (open, read, write, exit), but once you build a standard library for yourself (eg keep the design re-usable), it becomes a once only task. For my current app, I just need to change 1 define can it can be built for either Linux, FreeBSD, Windows or as a general object file to be linked to libc... so cross-platform assembly is possible, provided you're smart about the design. (And don't forget to isolate ALL platform specific code into their own source files for easier maintenance). PS. GTK is pretty good performance wise, so don't worry about those that say otherwise. Just remember in this day and age, we spend more time waiting for the OS to do the stuff we request of it, than executing our own applications. -- Darran (aka Chewy509) brought to you by Google Groups!
From: T.M. Sommers on 6 Nov 2006 23:33 randyhyde(a)earthlink.net wrote: > > Xlib is a high level library. What's your point? All you're going to > do by *not* using the GTK is to write a whole host of widgets yourself > in your assembly code, just duplicating what they've done in the GTK. > Whatever efficiency you gain will be lost on the underlying calls to > Xlib. The notion of "high-level calls" is quite a bit different from > "high-level code vs. low-level code". You're not gaining a whole lot by > doing your widgets in assembly - the low-level Xlib code is still > *very* high-level compared with machine code. I would say that Xlib is very low level, compared to what GUI programmers are used to. Want a scroll bar? You don't just flip a toggle and have it magically appear. You build it yourself, piece by piece, you handle the movement of the bar by yourself, and you do the scrolling yourself by copying pixels from one place to another. Want a menu? Want a dialog box? Same thing. -- Thomas M. Sommers -- tms(a)nj.net -- AB2SB
From: randyhyde@earthlink.net on 6 Nov 2006 23:37 T.M. Sommers wrote: > randyhyde(a)earthlink.net wrote: > > > > Xlib is a high level library. What's your point? All you're going to > > do by *not* using the GTK is to write a whole host of widgets yourself > > in your assembly code, just duplicating what they've done in the GTK. > > Whatever efficiency you gain will be lost on the underlying calls to > > Xlib. The notion of "high-level calls" is quite a bit different from > > "high-level code vs. low-level code". You're not gaining a whole lot by > > doing your widgets in assembly - the low-level Xlib code is still > > *very* high-level compared with machine code. > > I would say that Xlib is very low level, compared to what GUI > programmers are used to. Want a scroll bar? You don't just flip > a toggle and have it magically appear. You build it yourself, > piece by piece, you handle the movement of the bar by yourself, > and you do the scrolling yourself by copying pixels from one > place to another. Want a menu? Want a dialog box? Same thing. All this is true. But it is not low-level in the same sense as assembly vs. HLLs. You really don't gain a whole lot by doing the low-level stuff yourself. Cheers, Randy Hyde
From: T.M. Sommers on 7 Nov 2006 00:14
randyhyde(a)earthlink.net wrote: > T.M. Sommers wrote: >>randyhyde(a)earthlink.net wrote: >> >>>Xlib is a high level library. What's your point? All you're going to >>>do by *not* using the GTK is to write a whole host of widgets yourself >>>in your assembly code, just duplicating what they've done in the GTK. >>>Whatever efficiency you gain will be lost on the underlying calls to >>>Xlib. The notion of "high-level calls" is quite a bit different from >>>"high-level code vs. low-level code". You're not gaining a whole lot by >>>doing your widgets in assembly - the low-level Xlib code is still >>>*very* high-level compared with machine code. >> >>I would say that Xlib is very low level, compared to what GUI >>programmers are used to. Want a scroll bar? You don't just flip >>a toggle and have it magically appear. You build it yourself, >>piece by piece, you handle the movement of the bar by yourself, >>and you do the scrolling yourself by copying pixels from one >>place to another. Want a menu? Want a dialog box? Same thing. > > All this is true. But it is not low-level in the same sense as assembly > vs. HLLs. That's why I said "compared to what GUI programmers are used to." I think some people have the impression that Xlib has, by itself, the same functionality as the Windows API, and calling Xlib "very high-level" may have unintentionally reinforced that impression. -- Thomas M. Sommers -- tms(a)nj.net -- AB2SB |