from page 58 of Burgess (describing MMURTL):
"Paged flat memory is a variation on simple flat memory.  With this scheme, chunks of physical memory, called pages, are allocated and assigned to be used as a range of linear memory.  This is still a flat scheme because all the programs will use the same linear address....With this scheme, the linear address range can also be much larger than the amount of physical memory, but you can't actively allocate mor linear address space than you have physical memory.  For example, your linear address space may run from 0 to 1 gigabytes, but only 16 megabytes of this linear address range may be active
if that's all the physical memory your system has."
Here, Burgess' otherwise EXCELLENT reference shows its age a bit, since, these days, computers do not routinely contain only 16 mbytes of RAM, as they did 15 years ago, when he began working on MMURTL.
In view of the tendency to incorporate progressively LARGER amounts of memory in ordinary desktop computers, I DOUBT that PAGING is necessary for BOS.  I suggest FORGETTING about paging as antiquated, a relic of bygone days, much like segmentation--completely useless.  All segment registers should be assigned to the same location, to create the flat model, and thereafter, skillful programming will assign CODE sections, and DATA sections, keeping track with excellent documentation, rather than using obsolete segment registers.  I cannot fathom, Christoffer, why you are still using segment registers for BOS.
64 bit cpu: 
Hmm.  I haven't even got a useable 32 bit OS, yet, can't imagine starting on a 64 bit version!!!
cheerio!

Maybe it is my misunderstanding.  Perhaps the key word, which I have ignored, until now, is "relocatable".  Why would BOS need to be relocatable?
Why can't BOS reside at a fixed address?
Wasn't the great need for relocatable code resolved by larger quantities of memory, that became easily acquired by virtue of their low cost?
In other words, is there some OTHER reason, now, in this era of plentiful, inexpensive memory, to create relocatable code?  Maybe I just fail to understand the scope of the problem!!!
I envision BOS loading ONE TIME, and ONLY ONCE.  Why would it be desirable to have it MOBILE, to be relocated somewhere else?
I can understand the situation, let's say, for instance, in a real time data acquisition study, outdoors, with only a small battery to supply power, that having LOTS of memory could be counterproductive, because of the need to conserve energy, due to the small size of the battery.  In that setting, where, there is perhaps, only 1 megabyte of memory (--is it possible to purchase such a small amount??), then, I can understand why someone would want to eliminate every unnecessary instruction and indeed, expel the whole operating system, to make room for the data pouring in, then, after all the data arrives, dump the data somewhere, perhaps onto a floppy, and restore the operating system on top of the same memory used to save the data.  But, I did not envision that sort of application for BOS, again, maybe I am too shortsighted.
I just do not understand why relocation is a useful property for an operating system, sitting on a desktop, with essentially unlimited power, and a huge memory available, that can be partitioned as desired.
So, my answer,  possibly completely incorrect, to your question below:
"...how would i  know when the program refers to "global" memory positions such as
0xB8000 or when it wants to put a 'A' in it's variable at address BASE+0x678 ??"
is VERY SIMPLE--
(Simple answers from simple minds!)
YOU decide where all data goes, not the operating system.
No relative programming.
ALL absolute.
No pointers, all arrays.
As I said, simple answer, maybe not to your liking.....
regards

I'd maybe create a service dedicated to this as opposed to the executable format doing the relocating. (IMHO) this will be very ugly. I know the goal of BOS is to have no protection but perhaps don't use the protection offered by paging, only the benefits. . The Intel documents offer great insight on paging and I don't think it would be too hard to implement. (Don't know how much harder it would be in ASM, in C it was pretty easy maybe 2-3 days. Then again I'm not too seasoned in ASM)

Good luck

I think you can just disable paging, then reenable it with the PDBR once you re-enter protected mode and everything would work dandy. Not sure about this though.

I know, just not sure how.. Especially if :

If BOS goes in (at program loading) and changes the programs jumps
and other addressing to add the base address (address to which the program got loaded),
then how would i  know when the program refers to "global" memory positions such as
0xB8000 or when it wants to put a 'A' in it's variable at address BASE+0x678 ??

I should try to study formats like ELF and such..

I'm not sure that EXE's is such a good idea, better to
design my own format then.

Here is the simplest format:

use32
        ORG   0x200000          ; where our program is loaded to
        jmp   start             ; jump to the start of program.
        db    'DEX1'            ; We check for this, to make shore it a valid Dex4u file.
 ;----------------------------------------------------;
 ; Start of program.                                  ;
 ;----------------------------------------------------;

start:

as you can see just after

 jmp   start             ; jump to the start of program.

is

db    'DEX1'            ; We check for this, to make shore it a valid Dex4u file.

This is checked tomake shore its a Dex4u file (as this codes for the OS Dex4u).
but most headers are full of other info like stack size etc.
This file needs to be loaded at "0x200000" for it to work properly.

Heres a example from a menuet64 file format:

use64

    org   0x0

    db    'MENUET64'              ; Header identifier
    dq    0x01                    ; Version
    dq    START                   ; Start of code
    dq    image_end               ; Size of image
    dq    0x100000                ; Memory for app
    dq    0xffff0                 ; Esp
    dq    0x00                    ; Prm
    dq    0x00                    ; Icon


START:

All file format are basically the same, but expect much more info to be layed out in a certain order, the loader uses this info to loaded the file properly.

If you do not need to relocate a file BOS would only need to do this:

        use32
        ORG   0x200000          ; where our program is loaded to
        jmp   start             ; jump to the start of program.
        db    'BOS1'            ; We check for this, to make shore it a valid Dex4u file.
 ;----------------------------------------------------;
 ; Start of program.                                  ;
 ;----------------------------------------------------;

start:
;do some code here
ret

To assembly it with fasm you could do this "c:\fasm test.asm test.bos
to run it you just need to load it to 0x200000
and than do "call   0x200000"
and it would run, but for being able to load it any where is not as simple.

PS: bubach, one way you could relocate files/modules etc, is to port fasm to your OS, find a free location in memory to load the file/module to, fill the location in the files/modules  asm file (eg: write a new  ORG   0x******** address ), assemble it and load it to that address.
This would only need to be done the first time the driver etc, is loaded.
It just keeps things simple.
The drivers asm file, could be deleted after its assembled.

bubach the 64 menuet part was in answer to python, i was thinking of this as a way round the relocate problem.
" one way you could relocate files/modules etc, is to port fasm to your OS, find a free location in memory to load the file/module to, fill the location in the files/modules  asm file (eg: write a new  ORG   0x******** address ), assemble it and load it to that address.
This would only need to be done the first time the driver etc, is loaded.
It just keeps things simple.
The drivers asm file, could be deleted after its assembled."

one way you could relocate files/modules etc, is to port fasm to your OS, find a free location in memory to load the file/module to, fill the location in the files/modules  asm file (eg: write a new  ORG   0x******** address ), assemble it and load it to that address.
This would only need to be done the first time the driver etc, is loaded.
It just keeps things simple.
The drivers asm file, could be deleted after its assembled.

Ah, ok.. So you mean like a absolute position for each driver/module, but specific to the
host computer.. Hmm, intresting idea..

notoka: I don't think you get my point.. i don't care that the OS, BOS is at a fixed address.
what i want is to have external drivers that can be loaded or unloaded at runtime.
so for example, if you load BOS and later wants to load a specific driver, you can,
without having to worry about which memory location to load it at or how big it is.
I could then just allocate some space anywhere in memroy for it and run it. This functionality
could also be nice for some sort of TSR programs etc, in the future...

So, does this clarify it?

/ Christoffer

notoka, i think bubach needs to be able to relocate a driver because if not, he will need a space for every type of driver and even then how much space should he leave for each driver ?.

I think a simple way would be to have drivers as asm code, with the org left blank, then free space can be found in memory, the address is than add to the org and assembled with fasm.
He will need to port fasm to BOS, but he is doing that any way.
As fasm is a fast assembler it will take no more than a second or two to do this.