flat assembler
Message board for the users of flat assembler.

Index > Compiler Internals > Question about internal FASM file functions.

Author
Thread Post new topic Reply to topic
sid123



Joined: 30 Jul 2013
Posts: 340
Location: Asia, Singapore
sid123
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:
Quote:

OPEN: (Opens a File)
Not really, simply searches for a file to ensure it's ok to write to.
CF on Error.
CLOSE: (Closes a file)
Does nothing basically,
CF if file not found
READ: Reads a file
ESI - File Name
EDI - Buffer
Loads a whole file into memory
Problem #1: FASM tries to read some bytes from a file,
this routine doesn't bother checking the bytes to read. It isn't
even possible in FAT16, Loading of files is done through reading
clusters into memory.
idk how i am going to implement this
WRITE: Write a file
ESI - File Name
EDI - Memory Buffer
ECX - Bytes to Write
CHDIR: Change to a new directory
ESI - Name of Directory (pathnames supported by either a '/' or a '\')
CF on error
RM_FILE:
Removes a file
ESI - File Name
CF on error
MK_FILE:
ESI - File Name to Create
ECX - Pre-defined as (1 minimum)
CF if file name too long
MK_DIR:
Create a directory (i don't think it's needed)
ESI - Directory Name
LSEEK:
Problem #2: Not provided. I am not a POSIX expert so I don't know what
lseek is supposed to do, it sets a pointer inside a file name,
but why does such a system where the program has full control will need it?

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?

_________________
"Those who can make you believe in absurdities can make you commit atrocities" -- Voltaire https://github.com/Benderx2/R3X
XD
Post 01 Apr 2014, 06:54
View user's profile Send private message Reply with quote
DOS386



Joined: 08 Dec 2006
Posts: 1901
DOS386
> 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 Wink

> 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" ...) Very Happy
Post 01 Apr 2014, 07:52
View user's profile Send private message Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 17279
Location: In your JS exploiting you and your system
revolution
sid123 wrote:
... what changes would be needed in the internal FASM routines?
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.
Post 01 Apr 2014, 09:32
View user's profile Send private message Visit poster's website Reply with quote
sid123



Joined: 30 Jul 2013
Posts: 340
Location: Asia, Singapore
sid123
Hi guys!
Okay I have managed to teach the kernel about File Handles Smile
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 Smile
Any suggestions?
Post 02 Apr 2014, 09:54
View user's profile Send private message Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 17279
Location: In your JS exploiting you and your system
revolution
sid123 wrote:
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.
Post 02 Apr 2014, 10:11
View user's profile Send private message Visit poster's website Reply with quote
alexfru



Joined: 23 Mar 2014
Posts: 75
alexfru
[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.
Post 02 Apr 2014, 10:12
View user's profile Send private message Reply with quote
JohnFound



Joined: 16 Jun 2003
Posts: 3500
Location: Bulgaria
JohnFound
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.
Post 02 Apr 2014, 11:19
View user's profile Send private message Visit poster's website ICQ Number Reply with quote
neville



Joined: 13 Jul 2008
Posts: 507
Location: New Zealand
neville
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

_________________
FAMOS - the first memory operating system
Post 02 Apr 2014, 19:49
View user's profile Send private message Visit poster's website Reply with quote
Display posts from previous:
Post new topic Reply to topic

Jump to:  


< Last Thread | Next Thread >
Forum Rules:
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You can download files in this forum


Copyright © 1999-2020, Tomasz Grysztar. Also on YouTube, Twitter.

Website powered by rwasa.