How difficult would it be?

Can't you use the Linux version under BeOS? I'm not too familiar with BeOS myself but I know that somewhere on these boards someone was making BeOS programs using the ELF file generation capabilities of FASM and there was a little problem with it but then Privalov gave a workaround which worked for that person. You can maybe try that.

If the Linux version of the FASM executable itself won't work under BeOS, isn't there some sort of a DOS emulator you can install on it? I know there are DOS emulators for practically all OSes. Then you could use the DOS version of FASM to make BeOS executables using the code workaround.

All ports of FASM can generate code (using the same input files) for all of the supported output formats as far as I'm aware.

No, FASM for Linux will *not* run under BeOS (I've tried!). A workaround solution could be achieved using Bochs, but it's far from a practical way to do program. I'd also like to see a native BeOS port of FASM. It'd be somewhat difficult though, as the BeOS system calls are not well documented, and it's easy to crash BeOS when invoking them outside of the C libraries.

Doing a native port for BeOS is not hard at all.

You will need to port very few code, all located in system.inc and in particular: basical file manipulation functions and environment function.

I will do it but I have my time fulfilled for several weeks.

Gracias, pelaillo, vere qué hago.

He estado investigando el tema de un port a BeOS pero el problema es que BeOS carece de 2 llamadas al sistema:

1. brk
2. sysinfo

Alguien tiene alguna idea?
Sorry for the post in spanish but i think you can understand me, don't you, Pelaillo?

Thanks.
Gracias.

Well, take it and port!

Hi neonz, I think he was doing a real question, not a rant.

NULLPointer, we will need to do some tests before getting this working, but there is always a start...

If this file is from asmutils, and i'm sure it is, then i've already read it and i repeat:

there are two syscalls that BeOS miss, BRK and SYSINFO.

How do i manage that??!!
Any idea?

Thanks for your attention.

We don't need to do a verbatim translation. We could write code that do the equivalent operation. For this case in particular (there's only one call to SYSINFO), Fasm needs to reserve a big chunk of memory, so we need to find some alternatives and choose a good one.
A starting point could be doing tests with mmap or maybe is safer to disassembe some C written program (opensource of course to avoid infringing the law )

Maybe you could check out source of MenuetOS port. When fasm was ported to MenuetOS, it (mos kernel) hasn't any memory management system calls yet (AFAIK they simply defined data segment size in executable header and used fixed size buffer).

If fasm uses BRK to increase the data segment size, could i use malloc instead?
After all malloc is like a wrapper for brk, isn't it?

Thnks.

Don't know about BeOS, but in Linux malloc() is C function that calls BRK syscall.

Please check out this: http://board.flatassembler.net/topic.php?p=10643

It's almost working at last (see http://board.flatassembler.net/topic.php?p=10727#10727 for a longer post). I'll try to fix the single problem I've found with it and then all of us BeOS users can enjoy FASM.

FASM now works perfectly under BeOS! See See http://board.flatassembler.net/topic.php?p=10763#10763 for the download (source + binary)

I guess it's a little late for that now, but I had most of fasm ported to beos once using syscalls. If you still need it, brk is syscall number 8 on BeOS.

IMHO, pure assembly port will be better than one using clib.

Regards.

Does BeOS have a syscall for mprotect? This is one of the few syscalls my programs rely on heavily and I haven't found any decent documentation on the BeOS syscalls yet.

I agree. But libc port gives you a working fasm on such systems, and this should make developing any pure assembly port easier.