anyone used free gui's (wxWindows, fox, fltk, ...) with asm? :confused:
Posted on 2003-06-02 00:43:40 by kba
Only when a jiggow boring me. :mad:
Posted on 2003-06-02 02:18:08 by danneboy
yasm==tasm or it's something else ??
Posted on 2003-06-03 06:09:52 by AceEmbler
yasm is a NASM clone, it is only half finished last I heard.
Posted on 2003-06-03 06:17:58 by donkey
KBA,

I posted a similar question a month or so ago. No replies.

I also made a post on the wxWindows newsgroup about that time asking whether any of the wxWindows people had interfaced with asm. Again, no replies.

Interfacing with the three GUI's you mentioned all share the same problem, namely, they are all C++. This means that all of the function names are mangled C++ function calls. Even more troublesome is the fact that most of the calls require a "this" pointer.

Dave Cuny made a C interface to his Basic interpreter, but it is entangled with his interpreter. (Not a free-standing wrapper with C calls for external use.) He has indicated that he may work towards this later but needs help making it a dll so that it could be used just like any api (kernel32.dll etc.).

I know that this is an asm forum and I have learned a lot by being here, but I can't understand the lack of interest in questions such as you and I have posed.

After all, the api's that the people on this forum find acceptable are in fact dll's written in C (or C++ with an external C wrapper).

The ability to interface with these GUI api's would allow portability and would combine the utility and efficiency of asm with the portability and functionality of these GUI's.

All of the other wrappers I have found for wxWindows and FOX are specialized for thir target and thus not usable with asm (or c). These wrappers are for Python, Ruby, Eiffel, and others.
Posted on 2003-06-06 22:17:48 by msmith
I don't think a win32asm forum has much interest in portability.
Posted on 2003-06-06 22:27:44 by iblis
iblis,

Really???

A search on this forum has 111 posts including the word "Linux" while the fasm forum contains 48 such posts.

Is a person who might be interested in portability to be excluded from interest in win32asm?

Most portability issues are concerned with win32 as the base of the portability equation simply because of its widespread use.

Nobody talks about portability between Mac and Linux, or Linux and HPUX, etc. It is always between win32 and something else. It is always win32 and Linux or win32 and Linux and Mac, etc.

fasm is portable to win32 and Linux.
Posted on 2003-06-06 22:50:17 by msmith
Right, I never said there was NO interest did I?

The plain fact is that this forum's main focus is for assembly on the win32 platform, so don't be surprised when not very many people reply on other topics. I myself take great interest in portability, but when I want to discuss it I go elsewhere.
Posted on 2003-06-06 23:01:28 by iblis
I think that portability is important but not a task for asm. It would be difficult to find a language that lends itself less to portability than asm.

Asm is not object oriented, all it does is store, modify, push and call. We do not have the luxury of a level of seperation from the machine and the OS that is necessary to make porting code easier, and to write the libs that do this defeats the purpose of programming in asm. Even COM which is intrinsic in the Windows API is difficult to use in asm because of the indirection involved, portable code would be a nightmare.

I would like to see a lib for using wxWindows but I can't see ever using it, for me Linux just isn't important.
Posted on 2003-06-06 23:06:04 by donkey
Hi Donkey!

I agree with many of your points.

My interest in wxWindows is (was?) the appeal of a more orthagonal (regular) api. The ability to port to Linux would have been nice, but was not the driving force. Also free for the ride would have been the many controls in the library. On the down side, a 4K 'Hello World' program would not seem nearly as efficient if it were known that it needed a 3MB GUI lib such as wxWindows in order to work. Using a pure asm approach, we still need the system dll's, but they are "already there" anyway, so a real 4k GUI program is lean and mean as well as efficient.

What also occurs to me is the similarity of interfacing to the win32 api via asm or c. For example, while I have learned much of what I know about the api from you and other knowledgable contributors on this forum, I have also learned a great deal from:

http://www.winprog.org/tutorial/

which is the Forger's Win32 API Tutorial. At the api call level, there is almost a one-to-one mapping between c and asm.

BTW, I am NOT a c advocate, quite the opposite.

My remarks regarding portability earlier in this thread were to point out that there, in fact, are others in this forum who might be interested in portability witnessed by the number of times "Linux" appeared in the search. I am not particularly interested in Linux myself.
Posted on 2003-06-06 23:42:15 by msmith
iblis,

No, it's true that you did not say that there was 'NO' interest.

My point is that if I posted a message about "Using win32 asm to make an address book", no one would tell me that this "is not an address book forum".

If someone wants to interface asm to a GUI package, what is wrong or off-topic about that? It is a valid use of asm to do so, just like any other app.

My frustration concerns the fact that although the win32 api is written in c and c++, no one considers interfacing to it as off-topic or non-asm.

When there is a question about interfacing to another api in the same environment, it is considered non-asm. Why?
Posted on 2003-06-06 23:57:35 by msmith
I remember and i search a port writed in C, but i can find one, also i dont know, but some times maybe is more eficient use some of this tools, also i remember time ago, when i was trying learn UScript that in the reference or Epic, say that they manipulate best the threads than windows, they can manipulate more, i think if some free gui can manipulate some things like that more eficient than win api, is good to use.

I think seriously if some free API can do best than win api why not use.. you can search for the epic reference, i also pastee that paragraph here.


In traditional programming terms, UnrealScript acts as if each actor in a level has its own "thread" of execution. Internally, Unreal does not use Windows threads, because that would be very inefficient (Windows 95 and Windows NT do not handle thousands of simultaneous threads efficiently). Instead, UnrealScript simulates threads. This fact is transparent to UnrealScript code, but becomes very apparent when you write C++ code which interacts with UnrealScript.

source: http://unreal.epicgames.com/UnrealScript.htm


I really wnat a gui that can port my asm work to any OS.. that can be very nice.. hey, the people that are interested in this.. why us not do this?? aproach?? :D
Posted on 2003-06-07 00:33:53 by rea
use gtk, it's available for both windows and linux and in true gnome style pure C

I think bazik made an example with it in fasm


For me the reason to use little asm for crossplatform programming would be that not all platforms are x86 exclusive
Posted on 2003-06-07 06:25:09 by Hiroshimator

iblis,

No, it's true that you did not say that there was 'NO' interest.

My point is that if I posted a message about "Using win32 asm to make an address book", no one would tell me that this "is not an address book forum".

If someone wants to interface asm to a GUI package, what is wrong or off-topic about that? It is a valid use of asm to do so, just like any other app.

My frustration concerns the fact that although the win32 api is written in c and c++, no one considers interfacing to it as off-topic or non-asm.

When there is a question about interfacing to another api in the same environment, it is considered non-asm. Why?



Interfacing with it on win32 via asm is not off-topic. This still doesn't guarantee others are experienced or interested in it. You'll get the answers from the experience pool gathered here, on some subjects that might be 0 (zero). Answers are obviously never guaranteed.
Posted on 2003-06-07 06:30:52 by Hiroshimator
Thx for remember me that gtk is in C, the other day, i was trying remember and searching, but only remember wxWindow(free C++), qt(not complete free?? C++)... :S:alright:, i will download the cvs ;)
Posted on 2003-06-07 07:11:21 by rea
Yep, what Hiro said.
Posted on 2003-06-07 11:02:56 by iblis
The GTK port for Win32 has never really been completed.

http://www.gimp.org/~tml/gimp/win32/
Posted on 2003-06-07 11:11:01 by msmith

I think that portability is important but not a task for asm. It would be difficult to find a language that lends itself less to portability than asm.


Well, there's portability and then there's portability.
The most common form of portability people talk about, of course, is portability between different machine architectures. The assumption (which is wrong) is that code is automatically portable if you're running on the same CPU. Clearly, though, it's real easy to write a Win32 app that is not portable to Linux even when that code runs on the same CPU. This is one area where assembly language *can* be written in a portable fashion. HLA, for example, lets you write console applications that are portable between Windows and Linux (no, no GUI portability yet, but that's something that would be fun to add when time allows).


Asm is not object oriented, all it does is store, modify, push and call. We do not have the luxury of a level of seperation from the machine and the OS that is necessary to make porting code easier, and to write the libs that do this defeats the purpose of programming in asm. Even COM which is intrinsic in the Windows API is difficult to use in asm because of the indirection involved, portable code would be a nightmare.



Why isn't assembly object oriented? Obviously, all object-oriented language compile into machine code so it's clearly possible to write OO code in assembly. Both HLA and TASM support classes and objects, if you want to see formal OOP capabilities in assembly language.

As for library functions defeating the purpose of using assembly -- what do you think the Win32 API routines are? A very large percentage of the Win32 API calls people make could be written in assembly (and improve their performance) but you don't see too many people around here doing that. What's the difference between user-written library routines and those that Microsoft deemed important enough to include in the API? Beyond, the fact, that is of not having an expensive user<->kernel space switch?

Many assembly language programmers seem to operate under the assumption that library routines are slow. It's certainly possible to *misuse* a library routine and get lower performance than you would by writing a specific, hand-optimized, routine. But it's also possible that someone put a lot of effort into a library routine and it does much better than something a typical assembly programmer would hack out in a day or so.




I would like to see a lib for using wxWindows but I can't see ever using it, for me Linux just isn't important.


But imagine how useful Linux would be if you could compile your code against a library and have it automatically run code under Windows or Linux. With no further effort on your part other than learning the library routines? If you only write code for yourself, and don't care if anyone else would use your code, it's probably not worth it. But if you share code, not caring about Linux eliminates a large number of potential users of your code. Granted, Linux is a tiny market compared to Windows, but don't forget that most software users aren't at all interested in the kinds of applications most assembly programmers write. In that market arena, Linux has a fair percentage of user share.
Cheers,
Randy Hyde
Posted on 2003-06-08 22:54:13 by rhyde
a yep, i remember for what i am searching other portable library in C, gtk is only for GUI, dont port all the functionality like file acces, threads, sounds, imgs, net, like wxWindows, but i understand that is writed in the model OOP then is a little more dificult to use directly from asm, then i think that maybe a good solution can be use the standar C.. or ANSI C and use gtk. I think is suitable.

Nice day.
Posted on 2003-06-12 12:47:32 by rea
Posted on 2003-07-15 22:25:42 by kba