Using Turbo C++

[codemastersnake]

But can I use DLLs?

I know you've had a couple of answers relating to this already, but perhaps you need to think what happens when you use a DLL (or SO).

Your OS will (probably) consist of a kernel (+- modules) loaded in to memory by a boot loader. When you try to use a DLL, your host environment usually takes care of loading and linking with the DLL.

Now, because you are in an unhosted environment, your kernel will need to perform the dynamic loading and linking. This means that any disk drivers to access the DLL must be either loaded by the boot loader, or must be statically linked with your kernel. In addition, the dynamic linker itself MUST be statically linked (think about it ).

All of the above means that while you can use DLL's, you won't actually be using them until you have a few other things in place.

Cheers,
Adam

Does this means that we can use sys files also from windows/system32/drivers/ to be used with our kernel?

[ru2aqare]

Does this means that we can use sys files also from windows/system32/drivers/ to be used with our kernel?

Not unless you implement or emulate the Windows driver framework...

[codemastersnake]

Does this means that we can use sys files also from windows/system32/drivers/ to be used with our kernel?

Not unless you implement or emulate the Windows driver framework...

And how that can be done?

[ru2aqare]

And how that can be done?

By implementing how Windows communicates with its drivers. Although it has documentation available on MSDN, it is rather a large undertaking, and you probably won't see results for a long time... I believe ReactOS is taking this approach.

[Combuster]

And how that can be done?

Bla Bla Bla Bla Bla Bla Bla
Bottom line: you don't.

[codemastersnake]

And how that can be done?

Bla Bla Bla Bla Bla Bla Bla
Bottom line: you don't.

Who knows? May be someday...

[TheDragon]

Who knows? May be someday...

That's the attitude I like! If we all say tat something is never going to get done, it never will. I think the reason Microsoft is so far ahead of all of us is it is not afraid to innovate. I DON'T want to start a flame war here, and please excuse me if I'm wrong (I've never actually tried Linux), but it is my speculation that the reason Linux hasn't dominated Microsoft yet is because they aren't putting things together well. One branch/distribution is pushing so far ahead that they leave absolutely no room for backwards compatibility. That is their downfall. And some are not pushing hard enough and are stagnating. No flame wars here, OK?

And Thank you SO much for your help on the compiler issues.

If ReactOS can do it, so can we!

[ru2aqare]

Who knows? May be someday...

That's the attitude I like! If we all say tat something is never going to get done, it never will. I think the reason Microsoft is so far ahead of all of us is it is not afraid to innovate. I DON'T want to start a flame war here, and please excuse me if I'm wrong (I've never actually tried Linux), but it is my speculation that the reason Linux hasn't dominated Microsoft yet is because they aren't putting things together well. One branch/distribution is pushing so far ahead that they leave absolutely no room for backwards compatibility. That is their downfall. And some are not pushing hard enough and are stagnating. No flame wars here, OK?

And Thank you SO much for your help on the compiler issues.

If ReactOS can do it, so can we!

He is not exactly wrong, however... ReactOS has many people working on it, that's why it can implement the said driver model. Most of the projects here, however, are one-man projects. It is simply not feasible to implement something that complex.

[TheDragon]

It is simply not feasible to implement something that complex.

Let me ask you how many hours a day are the team project people (not like Microsoft, volunteer groups, like ReactOS) and how many hours a day on average these one-man-shows are doing. I figured out that if I do an average of 15 minutes a class (I'm in school) (including lunch), I'd get about 320 hours a school year (7 periods, including lunch x 180 school days). This is 13 1/3 days of just coding...no distractions or eating . This averages out to about 46 good days(no meetings or anything) of regular 7-hour days(8 hours-lunch hour). And this is just in school. I could get a lot more done at home (which I usually do). And also, the segmented 15-minutes are much better because I get to really think about algorithms before writing them down. But of course, I have to type them up again...

[Combuster]

A quick google for numbers: we're talking 12 years of 56 people.

For one person that's 12*56 = ~600 years. That means you have 520 years that you have to make up for within your lifetime.

[TheDragon]

Well...It's still possible, right? Heh heh heh...

[TheDragon]

OK. So now I have a couple of other questions.

--Could I use TASM for the asm code, because I can't for some reason get NASM to assemble a source I labored over esspecially for NASM; it said it couldn't open it. Anyway, could I just go tasm <all sources> and then use ld (that's a linker, right?) to link them to my C code?

--Could I do the same thing, kinda, except use Turbo C and strip the files or just compile it and not link it?

--Any help with my NASM problem would be very much appreciated.

--What kind of compiled formats (bin, elf, pe, etc.) are needed for OSDEV? I am having a lot of confusion over this part.

--If you don't mind me asking, could you possibly fill me in on, like, the whole concept of bootloaders? (Though I confess I haven't done much research on that yet.

Thank you very much.

[LoseThos]

You could always use the LoseThos compiler. It's has 16,32, and 64 bit assembly/compilation. It's completely nonstandard, but I think it's better than the original syntaxes.

You develop and launch your OS from LoseThos. One primary difficult you will have with other environments is launching into kernel mode from other operating systems which try to keep you in user mode.

If you get stuck developing your operating system, the LoseThos code is there to help. the only problem is you don't have the internet for help or ability to view PDF files like the intel manuals.

http://www.losethos.com

What? No takers?

You would have to be a little nuts to take me up on this idea, but you seriously don't know what you're missing. My operating system is just the way I like it and my compiler's syntax is just how I like it.

A pet peeve of standard C/C++ syntax involves the precedence of the bit shift operators, << and >>. In my compiler, I made them exponential. Therefore I can say: flags= 1<<OS_FLAG1|1<<OS_FLAG2;

Seriously you don't know what your missing.

It's retarded that the standard Intel asm syntax uses the same thing for loading variables and constants

instead of

mov eax,glbl_var
mov eax,constant

mine has

mov eax,[glbl_var]
mov eax,constant


* Edit: oops, the precidence of >> << is already greater than | but I moved it ahead of "*" and "+".

[pcmattman]

The way you like it is probably not the way someone else likes it - in which case a compiler like yours with custom syntax the way you like it may end up to be a burden rather than a help.

My 2 cents, take it or leave it.

[LoseThos]

You are correct that difference is not popular. I changed from ASCII source code to full documents with graphics.

If you want to be popular, reinvent Windows. That's what people want -- the familiar, except that will fail because there is a Windows.

It's kinda like artists who only get recognition after they die. All of us who make operating systems have a choice -- try to be popular by using standards and essentually making an inferior imitation of what already exists, or try to overcome opposition by making something new and better. The same and inferior is terrible -- you must try for something better or there is no hope.

The more you use compilers and libraries and standards from other sources, the more limited your options and the more likely you are to reinvent poorly. I am adamently against the use of standards for new operating systems. For example, I have a FAT32 filesystem compatibility that's holding me back, so I'm not fighting the good fight as I should. With FAT32 compatibility, my file system has to be similar or chaos errupts -- like using all the same symbols in file names. I was hoping to make lots of string operators for fancy filename masks, but compatibilty with FAT32, which allows most operator characters ruined it. I was using "~" as a compliment operator in my filename masks, but that's a valid character in FAT32!