Wow, you've been busy...
Ok notoka, I see your point. But what if the OS has a total of maybe 4000 drivers, not going to happen with BOS but anyway...
That would take, hmm.., 80mb.
Now, if i only need maybe 4 drivers on my computer, and those four drivers was made last of the total 4000 it would mean that almost 80mb of RAM goes to waste, since i don't use those drivers and can't use that space for anything else.
with 256mb or more in total RAM i guess that you'll say "So what?", but in my opinion, thats bad design. really bad design. I rather go for paging..

Anyway, we can quit this now. I'm going to use the GDT and segmentation. It's by far the easiest solution. If i ever start coding for 64-bit it has to be on a completly new OS and done in BOS on my future "C" compiler..

/ Christoffer

Oh come on notoka, are you being plain serious? You just can't reserver 20 megabytes. That's a waste of memory. If an OS would reserve 20 megabytes of memory just for a few drivers, then I seriously would throw that OS out of my window. Although memory is cheap, doesn't mean you can easily reserve 24 megabytes. I really don't wish to your OS then . And I won't this implement in my OS. I'll go for relocation.

PS. You seem to have rather small drivers. 1024 bytes (1 kilobyte) isn't enough for a nic driver.

@64 bit: yeah, fortunately they left out the segment-sh*t. IMO segments are not needed anymore. But that's just my opinion ;-)

Hi to all! Sorry for disappearing for so much time ...
If you create a simple relocatable format you could use it for both executables and drivers. It will only need to have tags for position-dependent code that will be changed at driver/application loading time by the loader to reflect the real addresses.
I don't have too much time to write now... I promise that I will make some examples later... ( and maybe read more accurately all the discussion because I jumped a post or two )

Axel

I'll share with you an idea about a possible position independent format that I want to use in my os:

Reloc
Data
Code

Ok... Data contains initialized and non-initialized data. Code contains the real program instructions.
Reloc contains the informations about relocation. For example:

Reloc:
-location- is at 0x01 from the start of the binary.

Code:
call -location-

Your code calls a location which memory address is known only at runtime. Your loader, when loading the application/driver will know the starting location, so it can calculate the -location- and substitute it with the empty/dummy value at the ( exe start location + relative -location- address specified in Reloc )

I hope it's not too much confusing... maybe we could discuss it if you're interested... IMHO it's not too much complicated to implement, but I'm surely missing some other problems/features to insert in it.

Axel

Ok, so then i "only" need to specify the format and change fasm to assembly files that
follow those rules. Should be simple... Or..?
Dex, would you like to help with this? Maybe we can have the same format all three of us,
making it our own standard..

@Dex:
Oooooopppssss ... sorry! I jumped over your post
It's exactly the same thing you said!
We could make a standard structure. For example:
Header
Data
Code

The header may contain an initial tag to identify the executable type ( magic numer ) and the architecture ( Dex4u, BOS, etc ). Then, following the same structure, every OS could implement some "proprietary" tag along with the standard ones...
For example, my os will need to have some additional informations about routines/functions in the Code... and I'll add a subsection in the header.

@bubach, As we have not written our own assembler we are all, not 100% shore on this subject, so the best think we can do, is write 2  program with jumps etc, one with org 100 and one with org 0, we can then test what will need patching or not, by checking the code with a hex-editor.

This way we will learn how it works in the real world, rather than read  bits here and bits there,  and still not understand it.
Heres what we know so far, but we need to find where else it is added eg: "call print",i think we would need to add the base to the lable "print" .
**************************************************************************************************
Question:
What is org 7c00h ?

Answer:

It is very similar to org 100h. This directive instructs the assembler to add 7C00h to all addresses of all variables that are declared in your program. It operates exactly the same way as ORG 100h directive, but instead of adding 100h (or 256 bytes) it adds 7C00h.

For example if you write this code:
mov ax, var1

and the address of var1 is 10h

without ORG 100h directive assembler produces the following machine code:
mov ax, [10h]

however with ORG 100h directive assembler automatically updates the machine code to:
mov ax, [10h+100h]

and it is equivalent to this code:
mov ax, [110h]

org 7C00h directive must be used because the computer loads boot records into the memory at address 0000:7C00.

If program is not using variable names and only operates directly with numeric address values (such as [2001h] or [0000:1232h]... etc, and not var1, var2...) and it does not use any labels then there is no practical use for ORG directive. generally it's much more convenient to use names for specific memory locations (variables), for these cases ORG directive can save a lot of time for the programmer, by calculating the correct offset automatically.
*************************************************************************************************
All we need do, once we know what needs patching, is get whats at the address, add the base and put it back.

Isn't it just short jumps that are position independent, like jc etc? All "normal" jumps
and calls would use a absolute address.

@smiddy, nice to hear from you, keep us informed about your job and house.

PS: your talents have been noted on the menuet forum : http://menuet.2.forumer.com/index.php?s … &st=15

That will be good, once you have sorted the house out, as we need "really clever people like that Smiddy dude" .