Re: RosAsm Bliss, and NASM Bliss

o//annabee wrote:
This is only a tiny skeleton. A poor beginning.
Much is lacking. Like propper clipping, and 2 tons of functionality.
Its just a suggesting skeleton.

I call it a "work in progress"


I've been working on something like this myself using HLA OOP, it's
quiet a bit more immature at this time, but already portable between
Windows and Linux. It's taking me a lot of time to code this since I
have to figure out Xwindows while writing it.

From a glance at the code, and the diffrence between the Window
messageloop, and the linux one, I can maybe understand why. The Linux one
looks like a Troll compared to the windows one.
if win32, 4 lines of code, else 3 pages of code.

But I see there are some counter examples as well.

And now I see that the linux part does the caseing there as well, so that
is the reason?

Yes, the messaging cycles itself is not too different. With X-win, the
casing is done in the main message loop... or you could create a
winproc and pass it a pointer to the message structure.

So far, mine uses a window of the underlying GUI as the base window for
debugging purposes, but in the future, it'll be all custom drawn.

ok. I guess you dont want any advices on choise of tools..... :))

Is your choise of tools portable and does it come with a portable
library?

It's not as easy as you might thing to port between Windows and
Xwindows. Take a look to get the idea.

I think its hard to judge from the HLA code. The FillRect call look
innocent enough. And the clearing code. The events, which I guess are
Linux way, look a bit frightening. I got some code I saved away that Frank
posted some time ago, and will look at that as well.

Xwindows takes a different
approach from Windows, doing somethings better and others worse. One
thing that has be stumped now is figuring out a keymapping system
that's compatible between both systems and still fast.

Basically, the parts in the source are separated at compile time:

#if (os.win32)
...do windows related API
#elseif (os.linux)
...do Xwindows related API
#endif

http://home.comcast.net/~kyzra/hlafiles/guilib.tar.gz
http://home.comcast.net/~kyzra/hlafiles/guilib.zip


imo, theres a good example in your source for why I would call HLA a HLL
and not an assembler.

method tComponent.setText (txt:string);
begin setText;
USE (EAX);
if (this._text <> 0) then
str.free (this._text);
endif;
str.a_cpy (txt);
mov (eax, this._text);
ENDUSE;
end setText;

my own code would be

Section.SetText:
mov D$edi + Section.Text eax
ret

This little method does a lot more than what you propose to have done
in a single line.
1. checks to see if there is already a string allocated, if so, frees
the memory.
2. duplicates the string passed in parameter 'txt' (string library
function)
3. assigns the new string to the object structure.
What it does is store a string representation of the 'component'


I chose the HLA OOP for this library and coded in a more high level
format since the code mostly contains library calls (either to stdlib
or X-win/win). It would be no fun at all having to push all the
arguments manually. The standard library itself is written in a more
low-level format.

Otherwise, the HLA code doesnt look much worse than Pascal or C, and it
reminds me much of Delphi actually. But I be hard pressed to call it
assembly, because I look and look at all the source, but I fail to answer
several questions. And that is likly because you make some use of the HLA
standard library? For instance where are you memorymanager?

Yes, I make extensive use of the HLA library for a couple of good
reasons:
1. It's portable, which means I don't have to code kernel level.
2. It's already written in lower-level assembly and efficient enough
for my needs.

The memory manager is in the mem namespace and some (having to do with
strings) in str namespace. The standard library's memory manager is
already rather good and it's portable. It would serve me no purpose
except wasted days to roll my own.

The library overall is function heavy. If you look through the demo
program that makes use of the library (guilib.hla), you'll find only 1
assembly instruction "mov" and one register "eax" and this is by
design. I want anybody using the library to be able to quickly setup a
gui without having to worry too much about low-level details then they
are free to code the rest of their program in as low-level as they
want.


-sevag.k
www.geocities.com/kahlinor

.

Relevant Pages

  • Re: HLA Under Linux question...
    ... You ought to join that group, if you're not, Beth - that's ... where you'll find *serious* discussion of HLA. ... Looked much better in Linux! ... Did/does the Windows version look okay to you? ...
    (alt.lang.asm)
  • Re: what is the justification for all this?
    ... One bit of warning -- I've changed a lot of the command-line ... runs MASM if in Windows ... runs FASM (Windows or Linux) ... How many freakin' names does HLA need? ...
    (alt.lang.asm)
  • Re: what is the justification for all this?
    ... One bit of warning -- I've changed a lot of the command-line ... HLA v1.90 also expands the use of looking at the program ... runs FASM (Windows or Linux) ...
    (alt.lang.asm)
  • Re: UTF8 file handling APIs
    ... binary file which stores some string in windows using its API's. ... string and use wcslen and wcscpy it is misbehaving. ... wchar_t string in Windows, and are trying to read it in GNU/Linux. ... aware that for wchar_t, Windows uses UTF-16 encoding, and glibc in Linux ...
    (comp.os.linux.development.apps)
  • what is the justification for all this?
    ... One bit of warning -- I've changed a lot of the command-line ... runs MASM if in Windows ... runs FASM (Windows or Linux) ... How many freakin' names does HLA need? ...
    (alt.lang.asm)