Selfcontained programs
I have been thinking about the idea of selfcontained programs for some time, but i am more convised than ever that they will work. Some would say, that it would make the programs much bigger, but this will not stand up, as my whole kernel is about 45k and even that added to the program, could not be called bloatware. Some would say, that there is so many differant sound, graphic ,cards that you can not include them all, this is true, but nether can we make all the drivers for our OS's, so we end up using things like vesa, etc, which would work just as well from a lib. We need to use asm to our advantage and see what we come up with. As a test of feasibility, i will make the New edit for Dex4u as selfcontained as possible, so we can test how it works out in reallife. Any ideas on pros or cons welcome :wink: . PS: By selfcontained, i mean a program that just needs to be placed in memory at a certain address and jump to the start to run, but users no (or very little functions) from the OS it runs on.

I like the idea of selfcontained programs. That's feasible in a OS like Dex4u where you usually have not many programs running. It will be also a bit faster. DOS had a lot of libraries available at compile-time ( I mean... source code or static libraries that would have been linked together the application, not the .dll or .so we see all around here today ). It's something like that you want to do? I think that a selfcontained program needs very little support from the OS, too. It only adds complications to the programmer ;)

@AxelDominatoR, Yes thats right, like lots of (asm code) include file, with all the function you need, when you assemble it with fasm , theres a call in fasm, that only inc the used functions 8) . It would be more work for the programmer i agree, but his/her code would be more used, as more hobby OS would use it. Just thing of how good a fasm port would be, if all the OS need do is load it to a address and one or two other things 8) , i even see no problem to have a built in floppy driver and fat12 etc, say its 50k bigger, it would still be cool and usefull to a lot OS dev's. Thanks for your input :) .

That would be handy, for quick running and such, especially being an open-source os, that's possible while with other OS's (Cough M$), they're afraid of you seeing the code, so all the functions are "black boxes". I don't really see how this would be that much harder on the programmer, since loading libraries during runtime puts memory management right in their laps... especially given the fact that we use ASM, which is incomprehensible to most casual programmers anyway...

I think this is posed as philosophical question and I think that self contain programs have their place. Take the subject of computer forensics. In computer forensics you wouldn't trust the OS abstraction over low level information about what you are studying. You would take control of the system yourself with your own application in order to KNOW what is happening with in the given environment. This means total control. The down side of this thought pattern is that it means single program and nothing else. No real multitasking, unless it was built into the application, which in itself would turn into an OS, eventually. Regardless, I am for bootable applications, it means empowerment to the control of the application, fully!

@tonyMac, Its only harder for the programmer if there is no lib available so he has to write his own function, but that the same as the OS not having that function, built in, so your right, it probably will not be harder. @smiddy, The programs them selfs will not be bootable (although will be easy to convert), it more instead of having function built in the kernel, that the function with be in include file so people can add to them or mode them, before assembling them. eg: in the "gui pong" game, it was easier for me to cut and past my vesa font functions, from the kernel, including the fonts, into a inc file, to assemble with my game, than it was to do them by calling the kernel, this goes for windowing sys too. Take smiddy problem with screen size, if that function was in a inc file (lib) you could of modded it very easily, and once written it should run on Dex4u, BOS ,SmiddyOS etc. Thanks for yours valuable input 8) .

PS: By selfcontained, i mean a program that just needs to be placed in memory at a certain address and jump to the start to run, but users no (or very little functions) from the OS it runs on. In this case, RetroForth/4u is a selfcontained application, since it only uses the Dex4u functions to get the calltable, and exit. (The "syscall" word needs the calltable, otherwise this would be even more self contained) All I/O inside RetroForth/4u is handled by drivers I provide without relying on the Dex4u functions. :)

eg: in the "gui pong" game, it was easier for me to cut and past my vesa font functions, from the kernel, including the fonts, into a inc file, to assemble with my game, than it was to do them by calling the kernel, this goes for windowing sys too. This implies, at least to me, that such functions shouldn't be in the kernel then. If it's easier to copy/paste the fonts, functions, etc than to call them, they should be separated out, or the calling conventions should be cleaned up. (Which is preferable is debatable....)

I think "RetroForth/4u" is a great example, of how a self containted program can work, as you are the programmer of the program, it is a lot easier for you to customise the functions in the inc file then work with a set of set functions in the kernel. Also i agree, they should not be in the kernel, the only things that seem to work better in the kernel are the basic drivers. PS: The only reason we need a number of function in the kernel, is because people expect them :wink: .

Another reason is to shirink application size, however, no prog I've made has gotten near 10k, so I hardly think that's an issue at this point...

Thats the advantage of asm, size, even if we added the whole kernel to the program, it would only add 45k. I think at most it would add 20k or so, by using inc files, compeared to built in functions, i can live with that. But by having the functions in the kernel and include file, the programmer can choose, which is best for him/her.