Qbasicnews.com

i started this late at night... it's supposed to be a host for mutlitasked-scripts. it has its own "virtual assembly" language, used to define event traps. the whole idea is asynchronous execution - all calls are made through a unified, inspected message queue. currently it's not supposed to serve by priority... because i just execute up to 100 instructions of each trap every cycle.

anyway. when a trap sends a message to another trap, the sender is suspended until the target trap reaches its LEAVE instruction. LEAVE thaws the sender back, and execution continues where it was suspended.

it's mostly for theoretical testing... but now i ran into a strage ugl problem. i use ugl for it's superb hi-res-timer and keyboard handler. on my p4 2ghz i got ~50000 cycles per second, when there were no executing traps (just user input checks, etc.). i decided that i'd use a ugl timer to do only 20 keyboard polls per sec... which increases cps to 600,000. all good, only that at some point it dies.

blitz, any idea? it's plain text mode -- i hooked only the timer and keyboard.



[Flexibal>

When can we see some code/demo?. I think the idea is quite exciting. I am making a Fake OS using a scripting lang. that Zap designed. It works really great and it does exactly this that you described:

Quote:...when a trap sends a message to another trap, the sender is suspended until the target trap reaches its LEAVE instruction. LEAVE thaws the sender back, and execution continues where it was suspended...

Coding in qb again? Neato. Ideas? I dunno. 0.22 supports callbacks for timers. So you could get real multitasking, sort of. But you can't use any dos stuff when the cpu is in interrupt mode as it is with timer callbacks. Hmm, i dunno. No ideas.

i'll try to see if 0.22 makes any difference. besides, i'll revise/rewrite Vema... maybe this will help.

thanks anyway.

big basic:

code... well, i'll need to work on that a little more. currently it's v0.2, and i plan a first release at v0.5... i'll also need to write my script->vm opcodes compiler, so that i wouldnt have to manually list opcodes. in a few days...

only that i'm going away for two weeks as of monday.



[Flexibal>

AND

blitz -- how do i do callbacks in qb? for that i need function pointers... is there a way in qb to determine the address of a func? you didnt document those functions.



[Flexibal>

yes, i am talking to my self a little, but here's a download.

vema version 0.25

http://www26.brinkster.com/bitwise8/vema.html








[Flexibal>

BOOSTQB

Looks interesting. Glancing at the code, this is the closest I have seen to emulating/simulating some real operating system behaviour in QB/VB. The message passing code is very cool, it would be interesting to see a system call interface (with calls such as read, write and exec) created around it, leaving the lower level functions (such as keyup and keydown) to your virtual device drivers.

hey. i'm flattered to have your opinions on my stuff :bounce:

well, you see, my life is all about invention -- although until recenly, i havent been inventing anything that has not been inveted yet. that the nature of things, when you're living in a century where everyone invents a squared wheel of his own.

so... i invented message queues a while ago, when i was trying to write a game, in which game scripts would run on the game engine, only that it needed too much mem, and doing all the 32x32 graphics freaked me out. so i tossed it out of the window. and now i'm doing "low level" stuff again, which i like the most. i'm planning on making a real os one day, that runs programs in a vm, not directly on the cpu, thus a system crash is practically impossible. by the way, that is :wink: . i'm getting carried away a lot. and since i'm planning this will be "my last word" in the qb scene, i'm putting a little effort into it.

by the way, i improved my "multitaskingability"... the instruction-slicing didnt work well. now it works perfectly. one trap runs when i press ENTER and the other when i press SPACE, and the best thing -- each trap executes only 3 instructions per cycles, and resumes where it was left. works smooth. of course a more reasonable instructions per cycle rate would be somewhere around 100... but i'm wondering at what level should i share - at the owner level or at the trap level?

if you looked carefully at the code, you'd have seen "owners". owner 1 is reserved to the system, while the rest of the owners are customizable. in other words, an owner is like a process, only that it's meant to used solely to group traps, i.e., loading an owner will set up all the traps for that owner, the system will direct user input at the active owner, and when you unload an owner - all of its traps are uninstalled as well. when the system loads an owner, it sends it the MSG_APP_INIT. the owner must have a trap for that message, which serves as the entry point to the "application". but i'm getting carried away again :???: .

of course the system handles system-messages on its own, and no trap can trap a system message before the system. maybe i'll create hooks for that -- which will have the ability to eat a system message before the system does so, and thus mask out certain messages. but i dont see a real need for that, at this point. my traps and owners should be enough.

as for installing virtual device drivers... well, that is harder. first, it will require hooks. second, my system uses ugl's keyboard's handler, and because and qb is qb... and my "os" is a "virtual os", i couldnt perform machine code in traps. it's too dangerous, too powerful, and too imposiible. so what i could do is write a trap that check's ugl keyboard state. only that would require direct memory reading... risky and complex... but mostly, inefficient.

also, in the final version, there will be no instruction like VMI_CLS or VMI_DISPLAY -- they will be system-destined messages. but i havent implemented VMI_SEND yet, so...

plus, i'm getting this feeling i should restart vema. i think it got a little too crowded. so perhaps i'll redesign it with hooks, more efficient execution engine, and perhaps a "virtual hardware interface".

i dont know what you meant exactly by "system call interface (with calls such as read, write and exec) ", so i'd like it if you explain a little more. but assuming i got it right, this is how i'll implement a keyboard vdd:

the system would have a write/read interface, where you tell the system the device ID, and the system reads/writes what you want. that way, when i perform a loop that READs DEVICE_KEYBOARD at a given index, the system will return the value of the "device" (keyboard state) at the given index. this will surely be inefficient, but what the heck 8)

also - since the system also uses messages for that, why is it any different if a driver sends those messages? i just need someone to send messages when needed... dont care who does that ... and, since i'm not gonna have directx for vema - are drivers necessary?

Quote:(with calls such as read, write and exec)

so i see how a interface with read/write is helpful, but what is exec? what do i execute on a device?


thanksies.





[Flexibal>

All operating systems provide a system call interface which is how user-mode programs communicate with the kernel. Consider the C command printf, which prints a string of text on the screen and the the command fprintf which prints a string of text to a file. All that printf does is calls fprintf with stdout(screen) as the first argument. fprintf then makes the write system call, which is used to write to a device. The write system call can write to many different types of devices such as printers, files and screens. Having the system call removes the low-level work from user mode programs.

Similarly with the read command, most user-mode programs are interested in getting a string of text from the user. The user-mode program probably wants to know that the user typed "hello", rather than pressed the H key, released the H key, pressed the R key, released the R key, pressed the Backspace key, etc. The read system call provides a more high-level abstract way of getting input. You can still provide raw-tty(terminal) calls for programs like games that require a more fine-grained approach.

The exec system call is used to execute a new process. It is the equivalent of the Window CreateProcess(Check this, Im not a Win-Guru) system call. Other common system calls are open, close, getpid(get the current process number from the kernel tables) and fork(create a copy of the current processes memory space). What system calls an operating-system provides is a matter of design.

A simple kernel usually has its device drivers static linked inside the kernel. For example when your kernel receives a read system call (via a message) it could determine the device and then call the approiate handler. eg (psuedo code):

Quote:i'm planning on making a real os one day, that runs programs in a vm, not directly on the cpu, thus a system crash is practically impossible.

Im currently doing a research/coding project for my University to make Solaris MINIX portable to other operating systems and architectures. Solaris MINIX is a real operating system that is hosted as a single process on top of Solaris. Each process is a real execuatable and runs directly on the CPU and the kernel swaps them in and out using ucontext structures. Signals are used to simulate interrupts and all of the device drivers have been replaced with virtual ones which make system calls to the host. Im not sure that system crashes would be impossible, you still need to interface with the host, so theoritically you could do something wrong and bring it down, of course it is a much more stable way to develop operating systems, which is why Hosted-Linux exists.

Quote:although until recenly, i havent been inventing anything that has not been inveted yet. that the nature of things.
....
so... i invented message queues a while ago

Message passing and message queues are used in a number of real operating systems (especially micro-kernels), including MINIX to make system calls and send information between different parts of the kernel. Your implementation is very accurate though.