OSDev.org

I already know the basics of assembler.

And i don't think that the Intel Manuals are necessary (just yet)

Please help out Pype.Clicker.

Ciao ;D

Ok Berserk, let's put this in context.

In evolutionary terms I am neolithic man (sloped forehead, club and all), Pype and KJ are high school graduates, df and Tim are Einstein, and you are a primordial soup dwelling single celled organism with a predilection for consuming its own excrement

Now that's intended to be humerous, so don't get offended (Or at least not too offended), but you have to understand that nobody is going to spoonfeed you this stuff. You must have an understanding of what the computer is doing if you are going to work at the OS level and the only way you're going to get it is by looking through manuals and working your way through the numerous tutorials that exist on the web.

It doesn't matter how old you are (I don't know and quite frankly I don't care), being able to research a problem in order to understand how to solve it is an invaluable life skill and one which it is simply impossible to get far without in this field of programming.

Hit the search engines, read some manuals, find some tutorials and work your way through until you understand what they're doing.

The vast majority of people on this board are making an OS because they enjoy solving the problems, in fact that's probably the single qualification required for starting a hobby OS. Lack of programming skill/knowledge can be overcome, but that desire to find the problems and figure out solutions to them is something you absolutely need. Otherwise you'll find yourself giving up a few months down the line when you meet a problem nobody can help you with and you lack the skills to solve on your own.

And yes, you're still going to need to learn some assembly language. Even if it's only enough to inline some very low level stuff into your C code.

Anyhow, hope things start to pick up for you soon.

Curufir

I am going to do all that, after i get this function working.

Don't worry, i am going to put this function to very GOOD use ;D

I just want to do this function, then i will get to other stuff, start on other stuff

Ciao ;D

you can't DO this function, or many other thing sin an OS until:

1. you first learn assembly and fully understand it
2. learn and fully understand the way the CPU functions
3. learn and fully understand the CPU's features and why those features exist
4. learn and fully understand how to solve problems.

the reason i mention #4 is because i *seriously* doubt that there will be many people out there willing to debug your code for you, much less tell you how to do something.

if you're going to write an OS, learn how to write it. don't make other people tell you how.

there are hundreds of tutorials out there, nearly all of which are searchable on google. there are *YEARS* of USENET logs on http://groups.google.com that deal with OS design and development, including answers to every question you've asked here. there are literally gigabytes of documentation you could be reading right now instead of pestering the people on this board for answers.

in the future, PLEASE search google thoroughly, and if you still can't find it, search google groups thoroughly. if you STILL can't find it, try different search terms. if, after a year of thorough, non-stop searching you STILL haven't found anything that helps you, THEN come back here and ask a thorough, *SPECIFIC* and intelligent question.

now, if i seemed unclear at all about any of this, then go to google and look up some of the words i used.

hi guys ,

making OS is great stuff. but i got a few questions. i am new student of os -

1) why can't the programs compiled in one os work under some other os - i know their executable format is different - but can't we convert it to other os's format. for e.g. from .out to .exe for windows.

the system calls would be also same - the 'c' functions like printf() work by calling the assemly instrn. right - then atleast the programs can work on same architecture.

if we have unix and win on Intel archi. then we just have to change the executable file format - is this correct - please tell me ???

2) suppose i made an OS. then how do i make applications for my os. e.g. if i want to make a editor
program - then i should compile this in my os - then only can i run it - but then i need complier for my os - but the complier is itself a program - which is has to compiled or assembled - even for that we need assembler ---

so this seems to me like a chicken and egg situation .. wll this might be a trivial - but i am confused.

so os guys plz help me.
Thanks for reading my queries.

wow-pravin wrote: 1) why can't the programs compiled in one os work under some other os - i know their executable format is different - but can't we convert it to other os's format. for e.g. from .out to .exe for windows.

the system calls would be also same - the 'c' functions like printf() work by calling the assemly instrn. right - then atleast the programs can work on same architecture.

if we have unix and win on Intel archi. then we just have to change the executable file format - is this correct - please tell me ???

Excellent question, but unfortunately it really does not work that way. This is for a number of reasons, mostly to do with the system calls and the system's assumptions. I'm going to start by assuming myself that you are developing for the x86 platform (i.e., the PC, which Intel now calls the IA-32), but the issues would come up any time you have two OSes on the same system.

First, you have to realize that the standard library functions are not themselves system calls; they act as a wrapper around the system calls, so that they can be used the same way in different environments. The lowest-level functions, like fputc(), use the actual system calls to perform their operations. The system calls themselves can be radically different between operating systems. On x86 systems, they are usually implemented as either soft interrupts or as call gates, but even if the same mechanism is used by two OSes, the way each uses it is unique.

One result of this is that, while you can use a compiler like gcc to generate code for any x86 OS, you have to reimplement those parts of the standard library which use system calls, and recompile the whole library and the programs which call it, in order to use them on a new OS.

Given this, it becomes clear why, even an OS can use a given file format such as ELF (which has increasingly become the standard in hobby OSes, as most open-source assemblers and compilers can output ELF object files), it cannot use a program which uses system calls for a different OS.

Even if this were not the case, it is not always possible to either run certain formats on some OSes, or convert between one format and another. This is because not every format supports all of the same data fields and operations; in the case of Windows PE format, there are some system-dependent fields which Windows need to load the files, and which cannot be sensibly defaulted.

Last, and perhaps more crucial of all, is that different OSes have different memory models, register allocation policies, argument passing styles, user interfaces, etc., all of which define a framework which a program has to work within. Programs from different frameworks will make invalid assumptions (or the OS will make such assumptions about the program), with potentially catastrophic results.

This isn't to say it is absolutely impossible, but the effort of trying to do so would be extrordinary, and to very little gain. It is far easier to port a program from source code than from binaries.

Oh, for additional information about executable formats, see the book Linkers and Loaders by John Levine. HTH. CCW.

wow-pravin wrote: 2) suppose i made an OS. then how do i make applications for my os. e.g. if i want to make a editor
program - then i should compile this in my os - then only can i run it - but then i need complier for my os - but the complier is itself a program - which is has to compiled or assembled - even for that we need assembler ---

so this seems to me like a chicken and egg situation .. wll this might be a trivial - but i am confused.

Basically, their are two classic solutions to this problem. The way that things were done in the bad old days was to write a small monitor-assembler program out on paper, and then hand-assemble it, then load onto a(n) [EPROM|papertape|floppy disk], which you would then use to painstakingly write a file system, editor, etc. over the course of several months, hoping that you won't make a mistake that will force you to start all over. While it may give a certain thrill to the sort of butch Real Programmer who memorizes instruction timings for fun and creates new executables using cat >, it probably isn't a wise approach for a newbie.

The other method, used by any sane person on this board, is to develop your design on an existing OS using a cross-compiler/cross-assembler, and running it by creating a binary image of the system which can be raw-written to a disk. For this last step, you can use DEBUG or PartCopy (I recommend the PartCopy, as it is much easier to work with) under Windows, or dd(1) under Unix or its derivatives. In this manner, you would then test and improve it incrementally on floppy disks, preferably on a second machine, or in a simulator like BOCHS, to the point where you have enough of a kernel, file system, etc. to support porting a minimal development environment to it (or developing one for it). Any x86 assembler that can create raw binaries, and any compiler that does not automatically insert system calls or other system-specific material into the generated code, should be usable for this purpose.

Hey,

You mean after a whole year of searching, if i can't find anythin, i come back and ask here, do you do this?? do you search for a WHOLE year??

I just want to be helped with this ONE function, is that too much to ask??

Ciao ;D

You probably didn't search newsgroups:
http://groups.google.com/

They often have stuff you can't find other places(for OS dev stuff, search only in alt.os.development).


K.J.

Berserk wrote:You mean after a whole year of searching, if i can't find anythin, i come back and ask here, do you do this?? do you search for a WHOLE year??

i search until i find something useful or helpful. i studied bootsectors and filesystems for weeks before i started, and even then didn't start coding until i understood A20, p-mode, and interrupts well.

my point is that the information is out there. go look for it. i found most of what i needed to know within an hour or so of searching. some of the more obscure topics took a little longer. but i eventually amassed a collection of bookmarks (which is difficult to export) which i return to to read when i'm unsure how to do something.

if you seriously want to write an OS, start at the beginning - a basic kernel that simply boots and does NOTHING - and work from there. don't worry about implementing all of the features you want until you come to them. don't bother with graphics until you've got a working console. don't worry about v86 mode until you have a need for it. don't worry about returning to real mode unless you absolutely need your kernel to return to real mode. take it one step at a time. and from what i've seen, you're wanting to start at the end and seem to want everyone to do the work for you.

Hi,

I am going to go to the beginning, AFTER i get this function working, already trying to make the function work has helped me alot in assembler, i have learned quite a bit.

I just need to get this function working. And i am NOT getting other people to do the work for me, i am just asking them for help, And they have beem VERY helpful. Thank you Pype, could you help me out a bit more??

Ciao ;D

Just to clarify the point: what you want to know how to do is:

1. switch into and out of (and back into) p-mode
2. switch into video mode 13h
3. plot a pixel on the screen in video mode 13h
4. read and decode an image file
5. use the pixel-plotting routine to draw the decoded bitmap on the screen

Is this correct, or have I missed anything? Of these, 3 and 5 are the easiest to do, assuming that the rest are already taken care of; the others are all fairly complicated projects in and of themselves, IIUC. You may want to try skipping part 1 and write the screen-drawing code as a DOS program first, then try the p-mode coding afterwards.

I don't have any specific advice or help at this time, but I hope that setting down exactly what is needed has helped some in figuring out what you need to do.

This is what i want to do (NOTE: I do not want to decode a bitmap or even use bitmaps)

I want to switch to RealMode from my Kernel while in Protected mode, change the graphics mode, then go back to real mode and continue executing my kernel.

Then from the Kernel (while in Protected Mode) i will put pixelS, and do whatever i want ;D

That is all, And no i haven't sorted out any of it, i just want to know how to switch to RM from my kernel, then change the graphics mode, switch back to PM, and continue executing the Kernel.

And i want to do all this in a Linked ASM function (NOT that i WANT to do it in asm, but i don't think it's possible in 'C')

And i haven't done any of this yet, the function that Pype.Clicker gave me game me an idea of what i have to do, but i can't seem to put it together (Read previous posts)

So Please, help out if you can.....
Ciao

Berserk wrote: This is what i want to do (NOTE: I do not want to decode a bitmap or even use bitmaps)

I'm puzzled, then. The goal here is to draw a splash screen, correct? The image for this has to be stored somehow, whether as an image file or as data entered directly in your program. Unless you intend to vector-draw the image (i.e., as a sequence of lines defined by startpoint and endpoint coordinates) or algorithmically (as hard-coded series of pixel plottings), then it will involve an image bitmap of some sort (not necessarily a .BMP file, though). This in turn means that you will have to write a function to read an image file, or decode an image file manually and enter the equivalent data into your program.

I want to switch to RealMode from my Kernel while in Protected mode, change the graphics mode, then go back to real mode and continue executing my kernel.

I thought you were putting off coding you kernel until after you had written the function, but here you are assuming the existence of your kernel a priori. One of them has to proceed the other, somehow.

Then from the Kernel (while in Protected Mode) i will put pixelS, and do whatever i want ;D

That sounds rather vague...

That is all, And no i haven't sorted out any of it, i just want to know how to switch to RM from my kernel, then change the graphics mode, switch back to PM, and continue executing the Kernel.

And i want to do all this in a Linked ASM function (NOT that i WANT to do it in asm, but i don't think it's possible in 'C')

And i haven't done any of this yet, the function that Pype.Clicker gave me game me an idea of what i have to do, but i can't seem to put it together (Read previous posts)

I have, but I'm afraid I haven't been able to put them together, either.

OK, I can offer this much: I'll work on finding, or writing, a real-mode version of the mode switching and pixel-plotting functions. The latter will have to be rewritten for p-mode given your planned design, but it should not be a serious challenge.

A quick search on Google finds the following:

[*]Using Video Mode 13h tutorial from the DJGPP homepages. Gives example code for switching the video mode and plotting a pixel. You would have to replace the calls to _dpmi_int() with calls to your own "p-mode to real-mode interrupt and back" function.
[*]An assembly language tutorial for video mode 13h, also giving examples for switching modes and plotting a pixel. The examples use MASM, but can be easily changed to NASM. Pixel-plotting function is for real mode.
[*] brief discussion of video mode 13h, including an explanation (but no real examples) of plotting a pixel in p-mode.

I hope that these examples help; I'll see if I can do some work on a more specific and comprehensive example myself. I doubt that I will have the time, so I can't promise much, though. I'll also try to dig up more examples if you need them.

Hi,

I already know about most of those tutorials, and they help, thank you for your help.

And no the purpose is not to draw a spash screen, the purpose is to put pixels to the screen ;D, to form an image(s) ;D. I got a plan for this function, i just want it to be a surprise ;D (well, not really, i just don't want to tell you'se ;D)

I will put the pixels manually, i will make a windows c++ program to convert image files to this (don't worry, i am a C++ professional, kind of ;D...well no, i just wanted to say that, but i won't need help for this program, i am just telling you'se about it ;D)

So, thanx for the help, and i would appreciate an example, if you can make one, but if you don't have the time...doesn't matter.

Thank you for your help