Hello,
I am in process of porting FASM to a non-conventional operating system. The operating system supports directories and files through FAT16 file system, it gives the program access to all possible memory (runs in ring0) so there is no such memory allocation, there is no concept of file handle, loading and writing files is done through direct file names, arguments returned are null-terminated and are passed in ESI, (there is no need for the program to grab it from ESI, the application library will setup the stack and save the arguments for you).
I have managed to "run" FASM (by simply filling the display_char function, the rest are all stubs).
To give an overview of syscalls:

My questions here:
1. Would it be possible to port FASM to such a system? I think many of the functions rely on file handles, the system doesn't have a concept of file handles at all.
2. If yes what changes would be needed in the internal FASM routines?

> I am in process of porting FASM to a non-conventional operating system.

DexOS ???

> Problem #2: Not provided. I am not a POSIX expert so
> I don't know what lseek is supposed to do

RTFRBIL: http://www.ctyme.com/intr/rb-2799.htm

it had been around since M$-DOG 2.0

> 1. Would it be possible to port FASM to such a system?

YES

> I think many of the functions rely on file handles

YES

> the system doesn't have a concept of file handles at all.

bad

> 2. If yes what changes would be needed in the internal FASM routines?

Load your complete file into memory at OPEN, then send data on "fileread" and "lseek" in memory

Better idea: implement a proper file I/O system, as-is your OS is inferior to bad old M$-DOG 2.0 (now "open source" ...)

You should only need to change SYSTEM.INC but without a handle you will need to create some form of mapping, or fake a file handle, between calls to open/read/close.

If you find yourself altering the core of fasm routines then you are on your own so you will need to read the source to see what needs changing.

Hi guys!
Okay I have managed to teach the kernel about File Handles
It's a large table (for now) which contains smaller entries call file handles.
Each Handle is given a number which is what is returned when fopen is called.
read() has also been implemented, however remember that the bytes to read will
be rounded off to the next cluster (provided that it doesn't exceed the limit, kernel will take care of it)
Would this be problematic? One solution could be loading by rounding off to next cluster into memory and
then clearing the "extra" crap. Basically if FASM requests to read say 4000 bytes, and sectors per cluster is 2048, then it would be rounded off to 4096, and therefore exactly 2 clusters will be read. I'm planning to read the clusters into memory and then clear the 96 extra bytes, this can be problematic as it may destroy code or data which may be in the "extra" 96 bytes.
I'm not sure about lseek my file handle contains a "last known memory location" attribute, and lseek
works by taking the last known memory location as the location of the file.
And another solution as DOS386 mentioned would be loading an entire file into memory, and copying it on read(). This wastes memory, plus what if a nasty programmer tries to load say a file larger than a Gigabyte? Although source code files aren't larger than a megabyte, so... yeah
Any suggestions?

Yes. Make a proper file library. Don't mess around with all this restrictive and dangerous stuff that requires the application to do things correctly. If you make it properly flexible then you won't have to care about what current or future versions of fasm (and any other program) do when reading or writing files.

[lf]seek() simply says that the next file read/write will occur at the provided location in file. Works just like a pointer/address. The read/write will automatically advance that "pointer" by the amount read/written.

If you take the perverted path of padding files to sector/cluster/block sizes, spaces or ends of lines are probably the best throw-away input for an assembler/compiler.

KolibriOS does not support file access by handles, but FreshLib needs standard file access.

You can see how this file access is implemented in the corresponding library source file.

You might find looking at my fasm port to FAMOS to be useful for you. As a first step I created a "Memory-Only" DOS version of fasm which involved amending SYSTEM.INC and other modules. Full source code is included. See http://board.flatassembler.net/topic.php?t=9197