I made an OS in VB - want input for improvement

[veebee123]

I know this is going to sound ridiculous or like a kid's project or something, but let me explain.
I know it is not possible to make a real OS in VB, but what I made is basically a virtual OS that runs on top of windows.

The way that it works is that it uses a custom control for its own virtual "windows". Some of the apps and core features are written directly in VB6, but the user programs are a bunch of VBScripts running inside the MSScript control. They have an API that they can access which allows you to program apps for the OS. It's pretty cool. This is not a commercial project or anything, but I think it's becoming something that would be a nice OS for kids to learn programming. Eventually, I will make an "exe" format which will include the binary data along with the VBscript.

Anyway, I am running into a bit of a problem. I am trying to figure out how to do process management (ie yielding the CPU resources so that one script can not hog the whole CPU). I don't know how to do it. The vbscript control doesn't include the WScript object so I have no sleep function. If I make my own sleep function in the API, then it will pause the whole exe (essentially pausing the whole OS). How can I simply pause a script within the ms script control and yield CPU resources? I think maybe I will have to make a timer in VB6 and then inject it at certain point in the script after the user has written the script so that it doesn't make it kludgy to program.

I understand maybe it is not possible and I'm really pushing the limits of VB here. This is not even close to what it was designed to do, but I think there must be a way. I also considered launching the scripts with CreateObject because apparently this causes them to launch in another thread, but it didn't work. It would probably be better if every program ran in a different instance of the OS. I tried an activeX exe a while ago, but it also seem to pause the main process even though it was running in a separate exe.

Any other input regarding the OS is also appreciated.

[TTn]

I know this is going to sound ridiculous or like a kid's project or something, but let me explain.
I know it is not possible to make a real OS in VB, but what I made is basically a virtual OS that runs on top of windows.
... This is not even close to what it was designed to do...

Any other input regarding the OS is also appreciated.

Ironically, Visual Basic was originally designed for this purpose. According to Alan Cooper (our father), Visual Basic was supposed to be the front end of the operating system.
My suggestion is to make use of the real Desktop API's, ie CreateDesktop, SwitchDesktop etc. That way, the execution flow on the default desktop is suspended (aside) while your custom desktop or Workstation is open and operating. I made a prototype in VB.NET a few years back to securely navigate between these desktop spaces. It's possible in VB6 too. Good luck!

[wqweto]

I understand maybe it is not possible and I'm really pushing the limits of VB here.

You are pushing the limits of your understanding about what services an OS provides: processes, (cooperative) multi-tasking, STA appartments, multi-threading and general VB6 "COM confines".

Microsoft made the quantum leap to pre-emptive multi-tasking with Windows 3.x "enhanced mode" some 25-6 years ago -- it was not an easy one!

cheers,
</wqw>

[DataMiser]

Ironically, Visual Basic was originally designed for this purpose. According to Alan Cooper (our father), Visual Basic was supposed to be the front end of the operating system.

The original BASIC maybe but Visual Basic ? I don't think so. VB was designed to run under Windows which was designed to be the front end on a DOS system.

[TTn]

The original BASIC maybe but Visual Basic ? I don't think so. VB was designed to run under Windows which was designed to be the front end on a DOS system.

It may be just semantics, but here is a specific quote:

Alan Cooper - "When I originally sold this application to Bill Gates in 88, it was going to be the shell of Windows, and it was going to be user-facing and it had a very very simple language that I put into it"

Afterwards, they introduced a product code named "Thunder" titled "Thunder... ...the storm is about to break" that eventually became Visual Basic after that. That appears about 8 minutes into the documentary video on msdn Channel 9 page, where they are talking about the early window-ing systems.

[Elroy]

Personally, here's what I'd consider the minimum requirements to call something an OS:

• Somehow, through some media (CD, possibly floppy) be able to boot a machine from the boot sector in the partition table of that media. I'll forego actually doing partitioning and/or setting the PROM setup, as that's more of a hardware thing. But it's got to be able to boot.
• It's got to be able to transfer that boot information (boot sector, initial files in the root folder) onto other media (such as a hard disk).
• It's got to know enough about hardware to build keyboard, mouse, and screen interfaces. Also, some consideration of printer interfaces would also be nice.
• It's got to be able to execute some kind of executable. If this executable isn't a standard PE file, then the addition of an assembler with well documented API calls would be essential.

Things I'd allow and still consider it an OS (although primitive):

• Single threaded (i.e., no task-swapping or multi-tasking).
• No GUI. (So, I guess I'd also forego the mouse interface mentioned above.)

I haven't explored, but I seriously doubt that veebee123 has even made it over the first hurdle (bootable).

Best Regards,
Elroy

EDIT1: And, the more I think about this, I guess a core requirement of an OS is that it's able to manage storage on whatever media (hard disk, floppy, whatever) it knows about. In the beginning, that was the core requirement of an OS, and hence the "D" in DOS.

[baka]

as for me I wouldn't call it a OS if it need another OS to run.
I could however call it a virtual OS,
but for what purpose? we already have windows, to have a similar OS running on top of window seems a waste of resources.

no, to make a OS is very complex. sure, if we want to emulate something, maybe theres some benefits,
but most of the old machine are emulated.

a 16-bit OS that we can run 16-bit windows applications could be fun to have, a replacement of known virtual machines softwares + old windows.

[DataMiser]

I guess the main requirement imo to call something an OS would be that it is capable of being installed on a blank system, then be able to boot up and operate the system and for it to be any real value would also have to allow other programs to be installed once it is on. If it can not install and run on a system that has nothing already on it then it is not an OS.

[wqweto]

as for me I wouldn't call it a OS if it need another OS to run.
I could however call it a virtual OS,

Even this is an overstatement as this is no VirtualBox or VMWare or whatever virtualization technology there is.

This here is usually called "Shell" in terms of Windows. This would be a "Terminal" in terms of Linux.

cheers,
</wqw>

[Arnoutdv]

It's indeed just a Shell or Desktop replacement.
Nothing to do with an Operation System