OSDev.org

I'm writing a simple OS in Q-Basic. Some may think "You can't make an OS in QB" but, I'm trying anyway. I need some suggestions on the topic of Booting, Assembly calls, etc. [glow=red,2,300]ASSEMBLY[/glow] the most difficult to learn thing ever. But I'm trying. If anyone has any interest, your welcome to E-Mail me: [email protected] . ;D (To all of you QB peeps, Enjoy!) As soon as I finish a Alpha, I'll put up a Source Forge page, and invite you all to try it! Thankyou. ;D


Alpha Zetta Z - [email protected]

*Sigh* You do realize that QBASIC requires an interpreter...and as so you really can't. I mean honestly...you can't. It is literally...impossible to code an OS in QBASIC...

The closest you could come to doing so is making a normal OS and coding your own QBASIC interpreter into the kernel or something...but as QB is alone you won't get anywhere.

would you ever write your own QB interpreter, if you want to take advantage of e.g. PRINT statement, you have to give something to that interpreter that let it send characters to the given output device ... *this* is typically what an OS should do ...

Same will go for file access, graphical functions and all the other things ... so you'll actually be building an OS not in basic that will be limited to interprete BASIC ...

Most old system had just a BIOS and a BASIC as their 'operating system' and the user had to program the simplest 'dir' command with 'LOAD "$",8 : LIST'

hehe ...

god save the queen,8,1 )

C64 consisted merely of the bios and a buildt in basic interpreter. But hell, that machine rocks: turn it on and voila, here it is. you could even multitask with it, provided that you knew how to do it: hooking some interrupt routine f. ex. to the scanline counter of the video chip.

Well ... load "$",8; list is cool at all times *gg*

You can make a pretend OS in QBasic. Possibly program a virtual machine and run your OS applications on top of your virtual machine.
Normally virtual machines are byte-interpreters. You could program a software monitor, thread manager, fake file system, whatever, into a piggyback OS in QBasic to run on DOS.
Most code generated from QBasic relies on MS-DOS for just about everything. It may be possible to make a real-address mode 16-bit kernel in QBasic but you couldn't use 95% of QBasics built in capabilities. Most of all, you can't get pointers of labels in Qbasic as I understand it. If you can't do this, you can't do a lot of things that C or assembly can do that is almost required for OS programming. You couldn't make your own interrupt API (how are you going to point to your interrupts without label pointers?).
I guess you could put your OS routines in a known place for applications to access routines, but it would be messy compared to just using your own interrupt routines.
I wouldn't go as far to say that you can not make an OS in some dialect of BASIC, but that would require a compiler more flexible than QBasic. You can study *some* OS ideas/theories in QBasic using basic simple routines but you would (once again) need to implement a virtual machine. Give it a try though. Let us know what you accomplish PS: I'm a die-hard QBasic programmer also.

BTW: If you didn't know (some people don't), software like GIMI for example is NOT an OS, but nothing more than a shell for MS-DOS.

First of all, you _can_ do a qbasic OS.
But you will need a external linker and stuff, becasue qbasic does not do that..
And about the BASIC-functions, you will have to do like in all other OS programming. Write new functions in for example, ASM.

You can't make a true OS in QBasic, because it depends on DOS for so many features. As darklife says, the best you could accomplish would be a pretend OS on top of DOS.

Maybe a good way to explain it would be that you can make either a pretend qbasic, or a pretend OS. You can't just compile some Qbasic code and try to boot it as your kernel. I guess there IS ways to twist this rule (like Darklife said), but it's not gonna be a virgin Qbasic OS.

Besides, Qbasic is slow and inefficient, right?

St8ic wrote: Besides, Qbasic is slow and inefficient, right?

No, but *most* programmers who use it don't understand enough about programming for speed. Like any other compiler, there is fast and slow ways to the same algorithm. Since most QBasic programmers were/are n00bs, they don't take time to learn, or too new to the language that they neglect programming with processing speed time in mind.
I guess an OS could be programmed in QBasic given that the programmers definition of "OS" is twisted into meaning "monitor/emulator". Once again I'm talking about virtual machines, and there is no need for them considering how powerful modern CPUs are and address emulation (translation), virtual addressing. Though I'll bet in the days of 8086 programming, a VM didn't sound to bad (think of protection)
Put it this way- If a bootable, independent, interrupt driven, multitasking OS were possible in QBasic, would it really be worth the try to create? Not with Microsoft QBasic, but maybe a dialect of QBasic, if one were to exist.

bubach wrote: And about the BASIC-functions, you will have to do like in all other OS programming. Write new functions in for example, ASM.

You're correct about the idea behind writing new functions. However, even some of the very basic syntax of Microsoft QBasic relies on either MS-DOS, BIOS, and most definitely 16-bit code. The last one may not be a big problem, and MS-DOS calls and BIOS can be emulated where needed. You would then end up with your own MS-DOS clone in the background :p And I'd like to see anyone manage an OS API in QBasic. By the time this stuff is wrote in linked assembly code (and it wouldn't be just a QBasic code driven OS anymore!), you may soon find yourself wishing you just shot your foot because I'm sure sooner or later the OS developer doing this would realize how complex the situation would become if even possible to finish without running into some kind of major road block.

wangpeng wrote: *Sigh* You do realize that QBASIC requires an interpreter...and as so you really can't. I mean honestly...you can't. It is literally...impossible to code an OS in QBASIC...

The closest you could come to doing so is making a normal OS and coding your own QBASIC interpreter into the kernel or something...but as QB is alone you won't get anywhere.

I know... it stinks. :-[ What I do is make an EXE and start a copy of DOS under the D-OX OS framework. Auctly, thats how I made a project recently for School. (Just to inform the people: QB 7.1) I'm reading lots and making big discoveries, I got NASM (and the help file), DEV-CPP (and some free C++ book) as well as QB and (useless for OS-DEV) VB6.

wangpeng wrote: *Sigh* You do realize that QBASIC requires an interpreter...and as so you really can't. I mean honestly...you can't. It is literally...impossible to code an OS in QBASIC...

The closest you could come to doing so is making a normal OS and coding your own QBASIC interpreter into the kernel or something...but as QB is alone you won't get anywhere.

There was a compiled version of QBasic, but you had to pay for it.

srg wrote: There was a compiled version of QBasic, but you had to pay for it.

Indeed there was a language called QuickBasic which was compiled. The language itself was almost the same, without enough small differences though, that you could just compile all QBasic apps.

I think there's some confusion here (which doesn't matter too much, since the answer is essentially the same anyway) since some people seem to use the term QBasic to refer to QuickBasic. QuickBasic can do more than QBasic, besides being compiled.

mystran wrote: Indeed there was a language called QuickBasic which was compiled. The language itself was almost the same, without enough small differences though, that you could just compile all QBasic apps.

Not entirely true. I used quickbasic to try to learn assembly, and all it taught me was that quickbasic compiled programs are still not assembly. All I could see was some routine editing some values and jumping accordingly, with the routine being exactly the same in all "compiled programs". Tells me it's still being interpreted, but in a slightly faster way. Still sucks though .

As for OSDEV, this is really bad, since you have to support the interpreter

that's the case for most 'compiled' interpreted programs: you'll have an executable that actually contains the bytecode (which has all symbols resolved and replaced by something like "variable #i in the global dictionnary" or "variable #2 in the local dictionnary" or "user-defined function #3" and thus works faster than the 'ordinary' interpreter), the runtime library (with assembly code for PRINT, etc) and the bytecode interpreter that will perform the operations as the bytecode requets them ...

Note that it's not foolish to have a HLL language interpreter at this level -- C64 had it, and even SUN Sparc and latest MAC do have a FORTH interpreter in their BIOS and most of the dirty PCI configuration code is written in FORTH for them ...

What is (imho) foolish is to try to use such a bytecode-interpreted program to implement the lowest layers while the power of an interpreted language is that the runtime library is rich and made of native code ...

Do you wish to have the interpreter decoding "POKE 0xB8000+col*2+row*80,char" everytime you put a character on the screen ??