Doubt regarding user "Programs"

Question about which tools to use, bugs, the best way to implement a function, etc should go here. Don't forget to see if your question is answered in the wiki first! When in doubt post here.
Post Reply
yolda
Posts: 13
Joined: Wed May 27, 2009 12:56 pm

Doubt regarding user "Programs"

Post by yolda »

Hi again all, first ty for your support in my previous post it was helpfull and made me understand a lot of things i had not clear before.
This questions isnt much about non-working code, but about how to treat programs in my "pseudo multitasking OS".
(I am using C btw.)

I got my GDT, IDT, PIC, and PIT working already and right now i am facing a mental problem trying to figure out how to treat "Programs"
inside my OS. I say "programs" because they will be binary code loaded into memory with the kernel at startup.
An example would be my shell. The shell i got working now is compiled from a .c file into an .o thats then linked and loaded with the kernel by the bootloader.

Since i will attempt preemptive multitasking, i will need to save the current registers into the shell's stack, and some other information in a structure in memory and then switch to the next process stack and pop its Instruction pointer out so it can resume work. The problem is that i want to have 2 or more instances of the shell running at the same time, but as far as i can see, in C only local variables will be stored in the stack (here i guess that giving each shell a different stack will avoid problems caused by memory being used shared).
(2 sets of instruction pointers working on 2 different stacks with the same code wont yield a problem but i cant use the same global variables for both)

How do i handle different versions of global variables when the memory of the global variables will be the same for 2 instances of the same code without having to compile the same code twice or more under different names (to avoid linking problems and still get 2 different sets of memory)?

Is there a way to take the code and data and copy it from the original binary into a different memory location so i can create more copies of the shell in memory? (wouldn't this give me problems regarding pointers to the data form inside the new running code of one of the copies?)

Lol or is there a better way to create different instances of running "programs"?

Sorry for the mess i made about my thoughts on this matter, any help and insights can be helpful!
User avatar
NickJohnson
Member
Member
Posts: 1249
Joined: Tue Mar 24, 2009 8:11 pm
Location: Sunnyvale, California

Re: Doubt regarding user "Programs"

Post by NickJohnson »

How exactly are you implementing your "pseudo-multitasking"? If you have everything in one address space, you need to be able to relocate executables for just that reason. It's usually much easier if you set up paging and have each process in it's own address space, but it depends on what you're doing.
yolda
Posts: 13
Joined: Wed May 27, 2009 12:56 pm

Re: Doubt regarding user "Programs"

Post by yolda »

NickJohnson wrote:How exactly are you implementing your "pseudo-multitasking"? If you have everything in one address space, you need to be able to relocate executables for just that reason. It's usually much easier if you set up paging and have each process in it's own address space, but it depends on what you're doing.
I use the PIT to call my scheduler routine and change contexts.
I use the kernel a address page as a start to avoid ring problems for now.

Code: Select all

you need to be able to relocate executables for just that reason.
This is exactly my problem, how do i relocate the code and data of a specific binary object once its loaded into memory?
User avatar
Firestryke31
Member
Member
Posts: 550
Joined: Sat Nov 29, 2008 1:07 pm
Location: Throw a dart at central Texas
Contact:

Re: Doubt regarding user "Programs"

Post by Firestryke31 »

The more popular executable formats include a table of what to relocate. Which one you should use is up to you, but it definitely makes it easier to choose the one that your primary OS uses since it will make getting a compiler much easier. The first 3 common executable formats that come to mind are PE COFF (Windows), ELF (Linux), or Mach-O (Mac OS X). I'm sure there are others but these 3 (especially the first 2) are probably the easiest to find documentation for.
Owner of Fawkes Software.
Wierd Al wrote: You think your Commodore 64 is really neato,
What kind of chip you got in there, a Dorito?
Post Reply