Also is your OS bootable on something like Virtualbox?

Maybe I’ll write a conversion utility where you write your “source” CSS files in that nonexistant nested way. And it’ll just dump everything out in the disgustingly long and verbose list that every site has because there’s no other way(?).

I’m still pretty new to CSS, so my naivete may be getting the best of me at this point. Still cool to see that someone else out there thought of this too

This is a fully validated and verified version, it does not need
conditional hacks, iframe hacks, https hacks!
It has NO memory leaks and allows multiple event functions
to be executed BEFORE the document.body or document.images are fully loaded,
as well there is no need
to write those functions in a separate script and/or to put inside the
ending BODY tag! -
instead, all should be in ONE script before ending HEAD tag:

see the working test page * http://arieslink.sitebar.org/onload-1.html
(the script there is internal, look at the source code, minimal changes
were done to Jesse Skinner’s work, based in its turn on yours,
but all errors and warnings were eliminated)

Best regards,
Vlad

Just drop me a mail if you like.

Christian

window.onload = function(){
}

all is ok now, but i must wait that all the webpage is loaded for javascript execute my script…

Is there any other way ?

ANSI C was a very good move and some libs are portable too.

Bringing up say IBM clone might not be so hard and there are examples of amateur OS.

My historic background is embedded systems where in effect your code is all there is and might be a whole language. Never done this with massive systems though.

Lua is large, not small in the embedded context. It will however compile straight and just about run under DOS 16, done as an experiement and just needed careful compiler and linker use.

There is an enormous amount I could say but leaving out a lot of justifications and reasons why…

Either you accept Unix and do it all in Unix of some kind making Unix of some kind or accept reality and take the DOS route. Few Unix people ever understand what DOS is/was, wrong thinking.
It’s actually very clever and powerful, done in a small space across a lot of hardware, and simple, KISS principle. It is a personal computer not a holy mainframe, live with it.

One way is this.

Find a simple old computer, good IBM clone with IDE and straghtforward graphics, well known network card. That is your working system.

Bring that up using FreeDOS. You can also see if you can get wattcp working on the network card as a precursor for later use. (I could send you a copy of Lua which will run under DOS but is of very restricted capability, too litte stacks space, did run factorial.lua first time though, not useful only a proof of concept)

Back in the 1980s I did several things which here give some clues.
I ported a specialist Forth from CPM/80 to DOS. This was written (by me) in assembler. Made some minor changes and passed the source though an American Automation cross assembler (cost a lot of money). Because i86 and 8080/Z80 are very similar the result was a DOS executable.

This ran first time complete with disk access. Understand, CPM/80 and DOS and to at least XP there are a common set of BIOS calls, (first 16 I think) which are identical. Even the DTA is in both (disk transfer area).

Another thing I did was write the first 32 bit floating point Forth. This was in 68k assembler and aimed at embedded systems but ran on personal computers too.

Essentially there is a relocatable chunk which can be loaded into memory by a loader, go. (or work out of eprom etc.) At a definite place is a jump table, these are the hooks to the system.
Things like initialise, where is memory, readkey, write char, graphics… and so on, all basic and only a very few are needed to have a text system. The correct OS addresses are set there and off you go.
Some very fundamental code has to be somewhere BIOS is part which is unique to that particular hardware, not a lot.

The next stage I will mention is perhaps look at Open Watcom, ex full commerical and a very good toolchain. This is actively in serious use… as a hint can target
DOS 16, DOS 32, DOS extender, QNX, Novell, Win 16, Win 32, Linux, OS/2

Will compile Lua and libs.

Lua is not yet really suitable for full embedded without a formal OS, got to get rid of the C OS libraries and calls are littered all over the source. Others are I suspect working on fixing this.

Compiling a say DOS 32 Lua and maybe it would work very usefully from FreeDOS.

Go to DOS extender and there is megabytes available and the start of crossing the barrier between real mode and protected mode to get at the BIOS calls for things like disk access.

wattcp should allow getting up TCP/IP, just needs a new personality source in Luasocket, currently usocket.c and wsocket.c
I guess it would work by crossing the barrier into wattcp running in real mode. There is an API of some kind, maybe you write it.

Graphics? Can start under DOS and go upwards from there. Libs if you know where to look. Rest assured that Linux and BSD go through hell handling graphics hardware, often needing to but can’t cross the barrier into real mode. Use VESA, life is too short to invent the lot.
Widget lib, try FLTK. Rumour it has been used under DOS. And see murgalua.

Then work on eliminating FreeDOS. Easiest is just accept it as a core boot loader. FreeBSD for example uses a Forth as a boot loader. Debian uses some kind of embedded VM to boot. And so on.
That Forth is embeddable and I guess boots in effect on BIOS.

Layers tend to be everywhere. What else is X but a layer sitting on a command line system?

Yes Watcom can run (gui) debug over a serial port or whatever, debugging the app on your new box.

Currently the Watcom DOS distribution is without a maintainer and is probably broken. So it might be difficult to avoid win32. Doubt that it works well enough under Linux yet to be useful.

I recently released a simple tool in C which helps in making static linked Lua, including Lua scripts. This might be useful before you have disk working (but feeding source via a terminal channel is old hat in the embedded world) Lua in fact uses this simple streaming of basic channels, io. does just that.

We were writing dll for DOS way back so that is no big deal.

Maybe I misunderstand.

You got my email address.

Tim