PureBasic Forums - English

Trond wrote:VC is a valid tool for writing an OS
Unreal Tournament 2002 is written in VC
Therefore, Unreal Tournament 2002 is a valid tool for writing an OS!

Well, that explains a lot. I've been Fragging my hard drive, which is why it's messed up now
I had best install VC so I can deFrag it.

I knew I forgot something. The filesystem must be in place for FASM to interact. The API calls PB makes, as a syntax, doesnt apply. If you rewrite the PB libraries (which means from scratch), then your PB compiler that you wrote from scratch would recognize.

If it's written with all the cross platform supported commands, then there are no api calls to worry about.

So it's possible, but how much work are you willing to put into the foundation needed? Boot Loader, partial Kernel, File System, porting FASM, rewriting PB and PB Libraries. That should be it.

PB, in conjunction with F/ASM, could write the other pieces.

If this is something you are truely interested in dedicating time to ... there are Boot Loader examples through-out the net, some OSDev groups to join, if you like Tutorials, and the like.

- "If it's written with all the cross platform supported commands, then there are no api calls to worry about. "

Very doubful. The compiler uses OS specific APIs under the hood in interpreting (possibly not the best word) your code. if you use OS specific APIs in your code then you will break cross platform compatibility but sticking with PB code means "PB will use APIs based on the target OS" -NOT - "PB will not use APIs either"

File system. somewhat OS independant. When the OS is in design stages a file system (s) of some sort will be decided on for support if its purpose is to read and write to some form of media.

It sounds like you are getting OS design issues confused with what compilers do.

The OS boots the system, then it usually (but doesn't have to): loads some device drivers, provides and interface for communication, exposes an API for others to use.

The binaries that do this can be written in a hex editor on another system!

Excel macros can write binary files with anything in them so I guess excel could be used to write an OS

My point is that you are barking up the wrong tree, "right tool for the job" If a dentist insisted on using a large hammer for every patient because it's a great hammer that's very expensive that he got for a good discount, (It could even be Thors hammer!) its still not necessarily the best tool for the job when his rich customers just want a polish

I remember reading the original macOS was mainly written in Pascal (with a bit of 68k assembly).

Not doubt full, the existing PB compiler must use the OS's API, and that makes sense.

If he was to make a PB compiler for HIS OS, he would have to do the same ... As we know, we cannot use Windows API in a PB application, and expect it to run on Linux ... the same logic applies here lol

I get the point It just looks like some miscommunication here

VC is a valid tool for writing an OS
Unreal Tournament 2002 is written in VC
Therefore, Unreal Tournament 2002 is a valid tool for writing an OS!

OK! It would be th first OS that would FRAG youand not the Hard Disk!

Logic is nonsense at the mathematic level anyway!

Oh Dear,
All wrong here.

Use Quick Basic and you can write an OS.

Why?
Which was earlier Visual Studio or Windows?
Ok right: Windows (called Windows 95) is the right answer.

Ok next step:
Which was earlier Windows 95 or Qiuck Basic?
Ahh...see and understand. You have found the right answer...so you knows the tool which is using to write all tools, Apps, Games, OS.

So easy: use QB and not PB and you will get all what you want....fun also.

Quick Basic used DOS. And all of the DOS laden interrupts. Also known as API's. It suffers from the same problems.

Let me give you a peek from my personal experience.

If you used any DOS based language, and you want to create the equivalent of an INPUT() function, that is, responds to the key presses, displays them on screen, and also handles when you press the back space key, then there wasn't an interrupt you could call that would do that from scratch, you had a choice: write it yourself, or call the DOS interrupt. All (and I mean, ALL) the languages took the second option. Why? Because they did not want to reinvent the wheel. That is what an OS is for - doing all the basic jobs for you.

Now while I was at uni, one of my classes was writing in pure ASM. And this is where I discovered this little nugget. Since I was miles ahead of everyone else, I decided to write my own INPUT() function that also handled cursor keys and the delete key. I used the interrupts provided by the BIOS, and would therefore always be available, whether I had DOS loaded or my own OS.

Then in my spare time, I personally went through a phase of writing an OS. I made some basic "hello world" and "hello, who are you" in ASM, compiled them with the tools I had at uni (I can't remember what it was called). I used Norton... Diskdoctor I think it was to open the compiled file and keyed in the machine code directly into the boot sector. And it worked. It was rather easy.

I had to give it up eventually because I couldn't find any information on how to jump from the boot sector into the hard disk normal space.

The end of this little ramble of mine is that, it concurs with everything already said: You will need ASM to interface with the BIOS interrupts for writing to the screen and taking keyboard input. Then you need to code a driver for handling disks. Then you need to rewrite the coding libraries for PB (the functions, but most importantly the compiler - FASM).

People think that writing an OS is trivial. It is. To write something that you can do something with on the otherhand, is not.

No modern OSes uses the BIOS for things like that, because BIOS interrupts are not available in 32-bit protected mode, neither to userspace programs or to the kernel. If the kernel wants to use a BIOS interrupt (like for gettings some info about the computer), then it has to switch to 16-bit real mode, do the interrupt, get the result and then switch back.
It's not really quick.

I admit, I was using an 80x86 to do this on.
32 bit mode was definately NOT on my mind

Foz wrote:I admit, I was using an 80x86 to do this on.
32 bit mode was definately NOT on my mind

Yes Guy...you are right.
All is possible....only belive on it