Here's: Dex4u OS, New dashboard (GUI) for you all to test:
http://www.dex4u.com/code/Menuet4U.zip
Here's a image for Qemu, but it needs hdd and atapi seting up.
http://www.dex4u.com/code/QemuDex.zip

Full code will be available, when bugs are out.
Screenshot: http://www.dex4u.com/images/Dash4u.jpg

EDIT:
Here is a ISO, for people without floppy drives, for testing Dex4u dashboard(gui).
http://www.dex4u.com/code/DexISO.zip

Note: The above ISO is for people without floppys, so when reading A: drive, its reading the floppy boot image.

works and looks great dex!

The Source code to Dex4u OS including GUI has been released and is available here: http://www.dex4u.com/download.htm

Regards Dex.

Dex4u rules!!!
Sources look fantastic!!!
I have a questions about debugging. When I try to write a bootloader I've used a tasm to have possibility to easy debug the code. How do you do this?

This may sound odd, but i have never used debuggers, if i have any problems, i useally print numbers every 6 lines or so, and see what number it gets to, also i print reg values, with the "write_hex32" function.
On top of this a letter is printed in the top righthand corner, if double fault etc.
Also try to keep things as simple as possable helps.
Thanks for you nice words .

Dex4u: nice to see someone else using the same method.

in my 512byte paratrooper project i was forced to do the same - except one little thing that i even couldn't do any output

i was using jump to exit routine to see if code reaches some particular location...

Oh no
It doesnt work in VMWARE

Looks like VMware still needs to do some more work to emulate a PC.
I have only tested it with DosBOX and Qemu, both work fine once setup right.
Thanks for testing.

I'm into this method too, it helps a lot especially when you want it to turn fast (at least, it is much better than doing the "Step In" over and over again ).

But IMHO, sometimes you need to "understand" the problem, not only just "find" it. I was very upset once, for a damn bug, and I found it pretty easy with that method. But then, I was so pissed off figuring out WHY it didn't work as expected!

The ONLY part of the debugger that I find "essential" is the "Memory Window" that displays the RAM memory. With this I was able to "understand" the problem, and realized that I had to modify my erroneous algorithm.

So, in short, I'm in the middle. I love the "classic" method without debuggers, but sometimes their assistance cannot be denied. It's a matter of choosing what's good from both sides. I always like to say that.


PS: debuggers can also be used to "reverse engineer" stuff. I used a couple of nasty tricks to crack some games and make 'em run without CDs for my friends... they were really impressed, but to the back of it, you only had to know a few tricks here and there. Of course, all this couldn't have been learned by a book, it's a skill you have to gain. And besides, I only did this because I wanted to apply some of my tricks (and my friends asked real nice) -- it's not something I'm interested in anyway, but it sure requires a lot of "tricky" thinking (and this was the part I enjoyed -- to think; it's not that I like "reverse engineering" much...).

I just wanted to say that debuggers can be used for others purposes too

I've been successfully using disassemblers/hex editors for the same thing.
Sometimes it's this "thinking" that is much more important than the set of tools you've got.

Agreed

I agreed with Tomasz Grysztar, also most people think programming is a science, but its also a art, the science part can be learnt, but its the art part, that separates the good programmer, from the great, like Tomasz Grysztar.

For me, if i have a problem i usually sleep on it and the answer come to me by morning, i can stayup all night, trying to solve it, with no luck, but if i sleep on it, it just comes to me, this always works .
This is for code of your own making, but for code someone else made (that you need to crack etc), than disassemblers/hexeditors are a great help.

Hello. I found one problem when I tried to add boot12.bin file to WinImage.
Program hangs with that screen.

Sorry this is in polish but means divide error. I tried use Menuet4U.exe with WinImage and it works perfect

@Viki, First thanks for testing , "boot12.bin" is the bootloader for floppy disk (first 512bytes), to use it, you put it in the same dir as "bootable.exe" ( you will find it in the folder bootpro/utils)
To use it put a formated floppy in the A: drive and type
c:\bootable boot12.bin A:
then enter, this will put the boot sector on the floppy.
Once you have assebled the source code add kernel32.exe and gui.dex to the floppy, just like any other file (cut & paste etc).

But you do not really have to do the above, if you all ready have make a floppy or image from menuet4u you just need to add the new kernel32.exe and gui.dex to the floppy or image.
Hope this helps.

ps: this may also help: http://www.dex4u.com/bootprog.htm

Yes I know this buy I try to test my and your os with bochs and with image prepared on WinImage. When I load whole Menuetos4U to WinImage and save it as a m.ima file on my hdd I can use it as fdd simulator. (for safe some time, don't need to restart ... ). Then I start bochs and see Booting from floppy message and then this:

I can not see the right hand top corner, but if you get a D printed there that because
i use a specal fdd driver for emulator like bochs, as the normal one does not work in emulators.

Let me know if this is the case and i will send you the code .

With floppy there is no D but something like this - and I think it's ok.
Problem is that with bochs after above screen kernel hangs

I have tested it and the floppy driver does not seem to work in BOCHS, but works fine in Qemu, DosBOX, and real PC.

With dosbox v0.65 I have the same screen as from bochs. This D on right top corner apears after few seconds