Re: Help with Enter and Leave Instructions

Frank Kotler wrote: 
Betov wrote:

Also, this is not only a matter of Graphical instance.
For doing something serious you must also have functions
for Files accesses,


Unix has everything you need to read and write files.

for Memory Accesses,

Right. The int 80h interface only gives us "chunks" of memory. We need to manage the chunks ourselves. The "normal" way to do this would be with the C library's "malloc".

The only standard way to do it is via malloc. Do anything else and you rely on undocumented, nonstandard, implementation details.

We can write our own "malloc", but I suspect they'll conflict if we try to do both.

It would be a problem only if you used your own memory allocation alongside malloc in the same program (not counting the above-mentioned problem of being nonstandard). There are replacement mallocs around, and it is no problem using them, as long as you use only them.

This could be a problem, since using any library - Xlib, say - is likely to pull in libc also. So we may be "stuck" with C's malloc, if we use Xlib. (shouldn't be a problem with "libASM")

Yes, it could be a problem if any library function you call calls malloc.

for Debug support,

I'm not sure what you have in mind here. ELF has two ways to put symbolic debug info into the executable ("stabs" and "dwarf"). Gdb and ald use "stabs"...

It is more that Linux uses stabs. FreeBSD uses dwarf, but both Linux and FreeBSD use the GNU toolchain, which supports both.

This is very discouraging, because, quite frankely,
if i had, for example, nowadays, to manage the tons of
Memory Chunks, that i manage, in RosAsm, the way i was
doing this, under DOS, ages ago, i would have better
suicide, than giving it a try.

Well, I don't know how you were doing it in dos. Memory management isn't easy, especially if we need it to be re-entrant (which I think we do). But I don't think it's worth killin' yourself over. Courage! :) 

Using malloc is pretty easy.

... and if all the competent Programmers around FASM have
to show is, at best, a 1980-DOS-style console Demo,

Since MS-DOS copied a lot of its command-line interface from Unix, saying that Unix has a DOS-style interface gets things bass-ackwards.

For "serious work", I'd be tempted to use libraries, but I'd still have an inclination to keep everything "in house". A library written in asm - even if by somebody else - would be preferable to a library written in C, for example.

I really don't understand the objection to using C libraries. I mean, they are libraries; who cares what language they are written in? The OS is writtin mostly in C, and no one objects to calling it.

--
Thomas M. Sommers -- tms@xxxxxx -- AB2SB


.

Relevant Pages

  • Re: ZLib double free bug: Windows NT potentially unaffected
    ... I've been researching this bug since I heard that ssh passes packets to zlib ... Double free vulnerabilities are primarily an issue for malloc implementations ... how exploitation of this error works entitled: ... Also as noted above some malloc libraries have explicit protection mechanisms ...
    (Bugtraq)
  • Re: So I want to exhaust a lot of memory
    ... But if there's a good reason for malloc() et al. ... at this point I would still prefer to check errno ...   standard_realloc, ...
    (comp.lang.c)
  • Re: So I want to exhaust a lot of memory
    ... malloc and friends' influence on the standard library or 3rd party ... at this point I would still prefer to check errno ...
    (comp.lang.c)
  • Re: [9fans] quantity vs. quality
    ... >>> Another example is using emalloc in libraries. ... > Well I wonder what people typically do when they can't malloc anymore ... > memory but need more... ...
    (comp.os.plan9)
  • Re: page sizes
    ... The documentation of malloc() on one of the ... Larger blocks allocate fastest if they are ... overhead by always putting chunks on cacheline boundaries (and wasting ...
    (comp.programming)