OSDev.org

I didn't see your question about recompilation until now, but I think others have adequately answered it. Running under an emulator or virtual machine is a different ballgame as far as I am concerned; otherwise, just the instruction differences and pointer sizes will mean a recompile is almost always needed.

Brendan wrote: (which also means that things like "malloc()" would have to be implemented in the kernel or in a shared library and can't be part of the application).

Not really. Malloc() will work fine as part of the application as long as it restricts itself to a tiny memory model. If the program wants more than 64k total, the kernel has to provide some sort of paging-based overlay system.

iansjack wrote: ... just the instruction differences and pointer sizes will mean a recompile is almost always needed.

I guess using byte-code instead of the exact binary instruction will solve the problem with different instructions, however I'm still thinking of pointers (generally). As I'm making the programming language also, so I'm totally open to experiment|integrate everything, but mostly I'm afraid to face some serious problems later when adding more features to the operating system, etc. because of the OS design and its structure.

I'm not really a fan of using an intermediary layer of bytecode in an OS, but that certainly is a way of isolating applications from the underlying OS implementation. I have no problem with the idea of separate versions of application programs for different versions of an OS. That may be because I am a long-time user of Gentoo Linux and FreeBSD both of which encouarage you to compile both kernel and userland to match the underlying hardware.

iansjack wrote:I'm not really a fan of using an intermediary layer of bytecode in an OS ...

Me too! ... Lets put it like this: you write the source code in plain-text, but you will release it in a byte-code format. If you wish you can release the source code as well, if not the original source code is protected somehow (at least until someone reveals your byte-code structure publicly!). User will run the byte-coded application. First time it might took a little bit longer, however the OS will store the pure-binary version of the executable somewhere, so it doesn't need to do all the stuff on the byte-code over and over again. It might be a simple Caching mechanism, or preferably kind of installation progress at the first run-time so you might even ask a couple of questions about customisation, then store the pure-binary at file system for the later usage. It's gonna reduce a significant overhead which usually virtual machines adds to the execution time. Whatever you need to deal with that, after the first run, is an absolute-normal binary code ...

P.S. By the way, thanks guys! I guess I got what I was looking for that ... :)

0x57 wrote:If I make a Segmented memory in Real Mode, but later change it to a Paged one in Long Mode, I have couple of options like switching to the compatibility mode to run the old applications, right? I'm wondering is there any chance to make the memory management mechanism totally transparent to the applications, so they could run without modifications/recompile and without changing the processor mode, which means your Real Mode application would run in Protected or Long Mode and vice versa.

Sounds Stupid-Impossible question, however I appreciate any ideas or inspirations, thanks!

P.S. I was thinking of adding a proxy between the application and memory manager. It could provides an API for the program so you can add kinda of meta-data to the executable files' header section, so the proxy would do the proper modifications to the binary, and then try to execute it.

P.P.S. I know that we do the similar thing in Relocation Table, however I think this one needs more modifications on the binary ...

I guess you could have a "converter" that converts a real mode dos exe file into a long mode win64 exe file.
There is no point - just use DOSBOX.