OSDev.org

Hello,
I'm trying to reserve space for my kernel, so that kernel would be exactly 128 kB long. But the last 30 kB's of the total 128 kB kernel size must be reserved for "external programs linkage" - sssh, its a secret , so 30,5 kBytes are available for future use for kernel itself (128 - 30 = 98 - 67,5 [uncompressed kernel size] = 30,5 kBs). So I want my kernel to grow into that 128 kBs by zeroing:
The problem is, FASM throws an error:
flat assembler version 1.64
KRNL386.ASM [349]:
times (100352-($-$$)) db 0
error: invalid value.
But if I move that "times" code along with the "TheSecret" label + "rb 30720" instruction above the "include" section, it works , but the executable is not exactly 128 kB long (the includes are taking +4 kB). I know, I would fix this by subtracting 4096 from the 100352, but every time I would change and rebuild includes, I would have to adjust that number every time, no? [This would apply too if I would replace the "times" with "rb 38400", but I would have to adjust it before every build I think]...

I saw this limitation in real mode, when kernel was too long in real mode (addressing above 0xFFFF), it freezed.

What should I do?
Thank you for your answer.

Regards
inflater

Use LD to link your object files together, instead of fasm. Then just use a linker script.

Why aren't you doing that anyway btw if you don't mind me asking? just curious

JamesM

JamesM wrote:Use LD to link your object files together, instead of fasm. Then just use a linker script.

Why aren't you doing that anyway btw if you don't mind me asking? just curious

JamesM

I would do that if FASM supported creating .OBJ files. FASM creates only standalone EXEs, COMs, ELF, etc... And my OS, well-modified DexOS with lots'a new functions, isn't "compilable" in nasm. Also FASM does not know the word EXTRN or EXTERN, so I think FASM with LD = impossible.

inflater

OK, well, you could just compile your kernel as normal, without the extra padding, then do an
so you get a plain format binary, then just write a small prog to load that binary in, write it out again and append x zero's to it.

Or you could write a small prog to parse the ELF file and do a similar thing, but that would be more difficult.

Does FASM define the 'end' symbol? it's usually defined as the end of the .text section, and if so you can use that do decide how many zero's to write in your asm stub:
?

JamesM

In fasm external symbols are defined with 'extrn' and global(visible in other files) symbols are defined by 'public' using ld and fasm together works just fine.

Sorry but my kernel isnt ELF It's an ordinary MZ EXE, does that count?
@frank: Yes, but "extrn" and "public" are only available at COFF or ELF. And rebuilding my bootloader to support ELF.... ehh that's more difficult than this simlpe growing problem...

Any ideas about that TIMES syntax? I'm forced to use the RB 38400 and change the number every change in the OS. Altough it's not a big problem, but I do not have any other easy choice I see.

Okay, thanks for your responses.

Regards
inflater

I haven't even heard of that format (only PE EXE)...

JamesM

It was the dos and early windows executable.

@inflater Maybe you should do what someone else said and just write a problem that appends the correct number of zeros.

EDIT: I think that $$ may refer to the start of the section not the start of the program/kernel. Also if you try to do it with the $-$$ your kernel will never be exactly the right number of bytes because the header for the executable.

Actually I preffered binary format as my OS kernel, but since APACK wouldn't accept "128 kB COM file" as it's very tied to DOS, I would try, say upx (along with APACK has better compression from upx, +5%).
@JamesM: If you do not use Windows, its not unlikely you didn't heard of MZ EXE Every bigger DOS program is using MZ EXE format. The DOS COM has one big limit: its size can't be more than 64 kB (derived from CP/M). Even WIN.COM as in Win9x is, is just renamed MZ EXE. But why? Thats a good question. Go ask Microsoft
Early Windows applications (2.0? 3.x -> 100%) used NE EXE format, if I am right

But absolutely everything that has the .EXE suffix (and its valid executable) is MZ EXE or just a more advanced version of it, it doesnt matter if PE, NE, LE (hybrid or fixed 32bit) EXEs - they all have signature "MZ" on the offset 0 Its a signature of some Microsoft programmer I think.

//EDIT: MZ means Mark Zbikowski

inflater

But absolutely everything that has the .EXE suffix (and its valid executable) is MZ EXE

no, the Os ignores the extension -- you can use .exe for CP/M files as well as .com for MZ's

But why? Thats a good answer. Go ask Microsoft

the reason for the file limit, is because CP/M files arnt supposed to be aware of segmentation at all (plus no relocation is done to the file -- so if you have a CP/M file larger than a single segment, you will not be able to access the remainder of the file) -- and the '.com' extension was assigned to CP/M files ported to DOS (original DOS was a lot like CP/M and was designed to make it easy to port the extensive software library of the most popular OS of that time period)

I wouldn't worry too much about the size of your kernel. 128kb isn't really that big at all. Mine is 88kb. I don't think you should be worrying about compressing it. I personally just use the compile for size option in gcc (Without it my kernel is 140kb.) It's my opinion that you should take the easy way first and then optimize later.

Well, my kernel after some experiment with TIMES has grown to 132 kB, and apacking it shrinked the zeros to 23,5 kB Of course, with compressing I would lose the "offset number of label PortixOS_Setup", but that's not a problem - my point is to create hybrid ASM&FP (32bit) kernel, because doing everything in ASM is hard. Of course FP slows some things, but I would like to make only built in kernel additions, in FP (and "raw-linked" to KRNL386). And I would link the FP binary to my OS kernel right before compression so that label offset is correct, and then - compression to shrink the kernel 128 kB is not too big, but I like small-looking applications

JAAman wrote:no, the Os ignores the extension -- you can use .exe for CP/M files as well as .com for MZ's

Oh sorry, forgot to add "... and its valid EXE executable" to my quote. Also I fixed the "good answer" to "good question".

Regards
inflater

Thanks for your help, I fixed the problem by specifying TIMES before the includes... It's not a big problem either, those includes are just files with reserved constants and variables. I do not change them much, so ... Again, thanks.
"Hybrid kernel support" complete... what do you think?



Sheesh, what am I asking for review of a helloworld application screenshot?... Anyways, you can make programs in free pascal for PortixOS using a special template now (will be on the web somewhere in September, yeah, PXOS 0.4 should been from 12.8. online along with new site design, sorry for that ), so the app doesn't have to be "raw-linked" to the kernel.

Regards,
inflater