Re: Significant Pure Assembler Application In MASM ?

Betov wrote:
Frank Kotler <fbkotler@xxxxxxxxxxx> écrivait
NH2Oi.2859$ai2.710@trndny05:">news:NH2Oi.2859$ai2.710@trndny05:


That'll help. You mentioned, not long ago, the *number* of APIs RosAsm
uses. When I was thinking of a literal "port" of RosAsm for LuxAsm, I was quite daunted by this!!! I was seeing a lot of APIs that, I'm not sure what they do, but I don't think there's a Linux equivalent. GTK *may* save your ass. I was contemplating *avoiding* libraries for LuxAsm, at that time... (I forget who it was that told me libraries
have nothing to do with asm. :)

Save yourself from irony, here.

Only the last part is intended to be irony.

The OS functuonalities *need*
libraries.

I'm gonna frame this!!! Expect me to be reminding you that you said it.

The Linux int 80 does evidently not do.

What does int 80h not do?

So, as for
pointing out some replacement of the Win Api, what else but
GTK?

Wxwidgits? I dunno. There are a flock of "toolkits" (GTK and GTK+, unless I'm mistaken, for example). If GTK is a "replacement od the Win Api", okay... I'm not sure that's true.

This is a serious problem, and GTK is only one part of
the solution.

If it *is* a part of the solution. How far have you gotten with GTK? ("where are the links to your apps?" :)

The "problem" *may* be that you think you want/need a "replacement for the Win Api". That would be one way to do it. Another way would be to do it "from the bottom, up". Everything the libraries do *can* be done in terms of the int 80h services. It is a *large* amount of "everything", however! I've given this a lot of thought, and I *still* don't know which would be "best" for the vaporous "LuxAsm" or some like product.

Herbert's recent experiments encourage me toward the "bottom up" approach. Libraries would be "easier", no doubt... at least initially. But we could find ourselves "locked in". The "problem" with libraries, IMO, whether for asm or not, it that it encourages us to solve a problem in terms of the library routines we have available, instead of solving the problem by "doing what needs to be done and not doing what doesn't need to be done".

[assemble to elf]
This is something you could do, now, in Windows, and might be quite useful. Suppose your users had to run RosAsm itself under Wine, but could create native Linux apps. A first step.


Nobody would do that.

Might be true. Not that many people using it on Windows. (only "semi-irony" - I seriously think it's "too bad" RosAsm doesn't have more users. Wannabee likes it a lot. There *must* be other people who would like it a lot. They're missing out.)

Maybe I should make it clear that I think this "native Linux app" that "users" might be doing in RosAsm-under-Wine would be RosAsm-for-Linux...

* Compile RosAsm as an elf.

Not that useful. *Maybe* after you've got it ported to GTK (if that works out for you). What I'd do, after implementing the elf format, is
rip the "eye candy" out of RosAsm and assemble *that* as elf. "just
the assembler" plus whatever else *isn't* dependent on OS - if the
"two click disassembler could be made to work - even if it worked by temporary files, rather than into a GUI - would be a tremendous help
in building the GUI back into it, in Linuxese.


you also seem to be completely missing what the word "Integration"
means, and what it implies.

Perhaps I flatter myself, but I think I do know what it means/implies - even "to you", to an extent. How "integrated" was RosAsm(SpAsm) when you were using other assemblers to "bootstrap" it? You're faced with the same situation again - not as bad, 'cause some of RosAsm *isn't* system-dependent - but if you expect RosAsm-for-Linux to burst into life fully integrated, I think you've got a hard row to hoe!

"First step", right?

Ubuntu is a more risky bet than ReactOS was 10 years ago, in my
opinion.

With the obvious difference that Ubuntu is distributing a working (if not perfect for Joe User) OS, *now*. Far in advance of where ReactOS
has *ever* been!


Seen that way, yes. But, at from another point of view, ReactOS,
if its ethical spirit had been respected, would evidently have
been the winner.

Woulda, coulda, shoulda...

Unfortunately, it failed into the hands of
definitive criminals, who made it collapsed in a very unexpected
manner.

I'm not ready to count ReactOS out. It's not looking good. When you first told me about ReactOS, it looked to me like it was going to be plan, plan, plan, and never write any code. I thought you were a fool to count on it. That didn't happen - they've got an almost-working code base. The apparent "problems" with that code base (thanks for the link) - or "uncertainty", at least - which is just as bad - *can* be fixed, in theory. Whether they *will* be is another story. ReactOS suffers from the same problem as Linux, anyway: not enough asm in it!

The success of Ubuntu is a completely differenet story. To date,
Ubuntu is quite close to the point where it would win the OSes
competition. "Will the market push it to an end?", is another
story:

You seem to make something quite "special" of Ubuntu, specifically. It's "just Linux", in my book. If they've got an especially good installer/configuration for "Joe User", good! - but any other distro can come up with as good or better at any time. "Put not your faith in princes" comes from the Bible, I think, so you won't like it, but... it's just a "brand name", Betov!

In the first case (ReactOS), it was mechanically self-evident that
it was a Windows killer project. In the second case, only history
will tell what is what. For now, i am in a complete expectation
mode, and my cristal ball is in silent.

Well, my crystal ball doesn't work worth *** when it *does* work, so... What was it that song said... "whatever will be, will be"...

and, as
a matter of fact, GTK does evidently not offer any Debug
Api like Windows does. Maybe those Api exist somewhere else
in Ubuntu (i suppose not), but if a real Processor level
Debugger is too be re-written, this is again, a couple of
years of works to be add to the price to pay.

the debugger will be the hardest job and you can do it
last. Your users can use ALD in the interim.

Or Jeff's AsmBug. Uses his own AsmLib, not GTK... It's a "work in progress" but seems to be improving nicely. Last version I tried still
crashed on Herbert's stuff... probably crash on RosAsm's elf executables, too... Could be fixed, I'm sure...


Sure. Tons of hard work, nevertheless.

Yes. And for what user base? I've been asked by newbie Nasm users, "where's the IDE for Linux?", so there's *some* interest in that sort of thing. I fear it's a small percentage of a small percentage - not that many Linux users, not that many of 'em interested is asm, not that many of *them* interested in an IDE.

My crystal ball *does* tell me that if it doesn't exist, it will have *no* users... it doesn't say if this is the end of the world or not.

Best,
Frank
.

Quantcast