It still seems like overkill to create an entirely new OS just to get around some minor annoyances with Windows. I'm sure you could find a way around whatever is annoying you (like maybe make your program for *nix instead), and not have to spend a lot of time on creating an OS. But whatever, if you want to create a new OS you can, and no one is going to stop you from doing so. We're just trying to give you advice.

I'm not writing an OS just to get around that problem, I'm writing one because I find it interesting and a satisfying challenge.

A very respectable and difficult challenge indeed I'll be interested to hear more progress on the internal workings of your operating system.

No one was trying to undermine you, we were trying to help you solve your original problem. If you don't care about solving your initial problem, leave it the hell out of your rant or make it very clear that it led you to something else you want to work on regardless of the solvability of the initial problem. We can only read what you write. Be less rambly and more coherent and you'll have less issues.



Frankly you aren't writing an OS at all. You've already said you are going to start with someone else's OS and build a shell. Nothing you are doing is at the OS level.



Learn to read. I said you won't get hardware acceleration with any open source kernel except Linux or BSD + X11, which is very much correct. I know *far* more than you do on this subject, especially since I've already written my own kernel. It's a very fun project, but you won't get OpenGL or any hardware 3D support.



Clearly you do as that is the only thing you've stated you want to write or posted a mock for. Perhaps you should go catch up on the terminology...

I'm just gonna ignore Killrnohj's post since I was already starting to get pissed off after reading the first sentence.

I've been having a little trouble getting started because I couldn't get VMWare to install, Qemu only did command line junk, and VirtualBox won't execute .IMG, .ISO, or floppy disk images. So, I surfed the web a bit and found a really helpful site called OSDev It shows you how to go about building an OS from scratch, pretty much holding your hand through everything.

With that, I think I'll drop Menuet and start from scratch ^_^


BTW, some people need to chill out. Me thinking of ideas for the GUI doesn't interfere with how the code will be written, and I don't appreciate getting badgered for doing so.

And for the last time,
NO KILLRNOHJ, I DO NOT WANT CREATE A WINDOW MANAGER. I
WANT TO WRITE MY OWN OPERATING SYSTEM.

That would make it fairly useless, wouldn't it? It can use ISOs out of the box (just start the virtual machine and select Devices, CD/DVD Devices, Choose a virtual CD/DVD disk file). Floppy drives are a little more involved.

Create a new machine. Give it a name, and set the OS and version to Other/Unknown. Give it as much memory as you feel is appropriate, and don't create a boot hard disk (unless you want a hard disk, I guess). Once finished, edit the settings, and go into Storage. Right-click in the Storage Tree and Add Floppy Controller. Select the floppy controller and Add Floppy Device under it to add a drive. Now you can select your floppy image, or leave the drive empty. To select a disk when running the virtual machine select Devices, Floppy Devices, Choose a virtual floppy disk file.

I just found out VB came with a tool called VBoxManage that can convert .IMG files into VirtualBox images. Thanks anyway though

That site is the bomb!

Your loss. I could tell you how to set it up such that your build spits out a bootable image such that you just need to restart your virtualbox instance to pick it right up, which allows for super fast iterations and very easy build->launch, but I'm kind of feeling like just telling you to f*ck off instead.



See, if you had actually read what people posted you wouldn't have had to hunt for anything, as I already linked to that site. Stop being such an arrogant twat and actually listen when you ask for advice. Or don't, doesn't matter to me. You came here, I don't care if you stay.

http://www.cemetech.net/forum/viewtopic.php?t=6880&postdays=0&postorder=asc&start=0#164774



Good.



You do now, you didn't before. Again, if you are starting with someone else's OS and adding a GUI to it, you aren't writing an OS, you are writing a window manager. Now that you are starting from scratch, you are actually writing an OS.

Anakclusmos, I appreciate the nod towards my experience in your post at the bottom of the first page of this topic, and hopefully you'll take that into consideration when I tell you that as much of a pain as Kllrnohj can come across as when he tells you things in his characteristic blunt and rough manner, in the past I've generally found him to be quite knowledgeable, and I'd say his key involvement in Android as a Google coder means he's not totally incompetent. If you're dropping Menuet and starting from scratch, I'd have to at least partially agree with Kllrnohj that you were originally thinking of something halfway between writing your own OS and your own WM/GUI/shell and now have decided to write your own OS.

Regarding your musing about people contradicting and undermining you, I hear your concerns, but I generally believe that it's a positive thing, as we have helped guide a lot of calculator programmers attempting to take on huge projects without fully realizing the scale to smaller projects that helped them complete something without getting frustrated. They were then able to move on to progressively larger projects, and although some felt angry at being told to scale back their plans, the majority later thanked us for helping them be realistic. There are other sites out there that encourage users regardless of how feasible or realistic projects are to their skills, and we choose not to take that route. By your own account, you are an experienced programmer (although your defensiveness about it makes me worry if other people have doubted your skills and thus made you regard suggestions meant as constructive as casting doubt on your expertise), so I'm sure you will understand the importance of starting small and building upwards, even if you're an otherwise skilled coder approaching a new area.

I guess it is a rather large leap, but I'm still willing to give it a try. And actually, my first idea before this was to create a framework somewhat like the GTK. Regardless, I think is far more interesting and still want to continue in this direction.

Back on topic, I figured out why my OS wasn't working. After
fiddling with it for a few hours trying to figure out why it wouldn't display text, I got frustrated and wrote a memory dumping routine. When I dumped the memory, it showed the same 4 bytes repeating
themselves over and over again. It never occured to me until then that perhaps the memory at which the bootloader is executed could be protected >_<

So, I rewrote my bootloader to copy the text to 0x7C00 (which I guessed to be safe memory to access since the bootloader's job is to copy the kernel to that address). The string printed without any
problems

I couldn't get much further after that though. I accidentally deleted my copy of the MenuetOS source code so I didn't have the libraries for Vesa on me, and without it, displaying text is pretty much all
I can do.

Oh and I speaking of which, figured out why I couldn't get MenuetOS to run in my VM. I accidentally downloaded the 64-bit version and my pc is 32-bit

I'm gonna go download my missing junk and hopefully make some progress this week.


Edit:
I was just reading through some documentation on OSDev.org and had to correct myself. Until now I had thought the bootloader copied the kernel to 0x7C00, but actually that's where it itself is loaded. This would also explain why I got strange repeating symbols from my memory dump. I had it pointed at the interrupt vector table, not the string

Before you bother with Vesa figure out if you are going to do a 16-bit or 32-bit OS, and get more of the plumbing in place first. You won't be able to do graphics until you can manage memory, for example. If you are going for 32-bit, you'll also need to setup the ability to drop back to 16-bit real mode to issue the interrupts needed to adjust video mode. Key input is kind of important, too.

By the way, bootloaders are kind of a pain to make - why aren't you just using GRUB? GRUB will happily setup a Vesa mode and spit you out in protected mode if you want.

Thanks for the suggestion I didn't say all of this before, but here's the basic plans for my os:

- 32-bit
- boots from ISO
- NedMalloc for memory management
- Vesa for 2D library
- Mesa for 3D library

I also toyed around this week with the bootloader and got an ISO working. (The only thing I really had to change was setting the start address to 0x7C0 instead of 0x7C00.) I understand the ISO 9660 file system pretty well, so it's just a matter of writing the driver.

I thought about using GRUB when I heard about it on OSDev, but wasn't sure. Will is still work for ISO's?

In which case you need to deal with all the protected mode stuff, which will take you quite a long time to iron out. (think months long)



Yeah, uh, no. Totally wrong memory management. That is a user land allocator (and looks like it's for Windows?). That has *nothing* to do with setting up page tables or page allocation.



VESA is not a 2D library.



You will never reach this point. Assuming nobody else joins your project (which is almost certainly true), you're looking at many months, likely years, before you even have rudimentary 2D graphics.

http://wiki.osdev.org/Beginner_Mistakes#GUI_Design



Yes: http://wiki.osdev.org/GRUB_2#ISO_instructions

Thank for the heads up on Nedmalloc. I was a little worried about it when i noticed it used other libraries like stdlib. Last wednesday, I started looking memory allocation a bit more and i think i'll give a try on my own.
Yeah, i know Vesa isn't a technically a graphics engine, but you get the point.
your comment about my mention of mesa...thats harsh...

Sadly, i can't grub since i'd need to install cygwin and i don't enough internet access. Was looking at osdev's atapi documention yesterday and realized im gonna need to write a driver for an IDE controller first just to read the disks. hoping all goes well

edit: sorry for my bad spelling, im on my ds and its easy to lose you place

Keep in mind stdlib doesn't exist until you write it.



I don't think you understand. VESA isn't for 2D drawing, it's just to setup the screen mode. It doesn't do any drawing itself.

wiki.osdev.org/Drawing_In_Protected_Mode



It's also very, very true. You really need to reset your expectations in a big way. Even just getting to the point of, say, MS-DOS is *very* hard and a *ton* of work. You will probably not get that far.



How are you compiling?

to compile, i'm using FASM. for any non-assembly code i have the GCC (mingw) compile but not asm/link and then assemble it in FASM like the rest.

EDIT:
Made some progress:

* Finished the bootloader
* Figured out how to enable Vesa
* Figured out how to enable the A20 line
* Figured out how to setup the GDT to enter protected mode
* Designed and decided on a filesystem called ARFS

Aside for a few awkward things like figuring out how to read from disks, this has actually pretty -e-a-s-y- ^cool so far.

Phew...almost jinxed myself there

Hey guess whaaaaatt....I figured out how enable Vesa graphics modes
Yeah, I said that before but I didn't figure out how to actually draw to the screen until now!

It was a little confusing at first, but it turns out all I had to do was

* Test if the graphics mode I wanted to change to is supported
using the AX=0x4F01 BIOS call, which writes a mode info block at the address I give it

* If the mode is supported, store the BPP, the bytes per scanline, and the physical address of the linear video buffer to somewhere I can remember. (all are found in the mode info block)

* Enable the graphics mode with the AX=0x4F02 BIOS call

I use a lookup table of 24-bit graphics modes ordered from highest to
lowest resolution and a routine that tests each mode until it finds
one that's supported. This way, the highest resolution is always
selected.
I don't completely understand the whole physical/logical address thing
yet, but after alot of frustration I eventually figured out that in order
to get the exact location of the start of the linear video buffer I had
to subtract 1MB from the physical address provided in the mode info block.
Otherwise, the drawing was shifted 85px to the right and 17px down.
(when running in a window size of 1280x1024 in 24-bit mode)

Of course, knowing me, the second I figured all this out I jumped straight
into drawing routines ;P About an hour later, I had SmileyOS!



AHAHAHAHAHAH!!! WINDOWS IS PRETTY, MAC IS COOL, AND THE 'IX's MAKE ALL
THE NON-PROGRAMMERS DROOL, BUT THEY SHALL DIE BEFORE THE EPICNESS OF
SMILEY OS!!!! >8D

*Ahem*
In the screenshot, the os was still running in real mode since I didn't
want to fool around with paging and memory mapping the video buffer
to somewhere I can use it. The sprite is actually only 8x8, my sprite
routine draws the image 8 times its size


Code:

I've also made a bit more progress since taking the screenshot. Below is
a list of everything I've done so far:

* Designed a filesystem called ARFS based on observation of
FAT and Ext2 filesystems. It features large filesizes (>4GB),
the use of unicode and non-unicode naming for filenames up
to 256 characters, basic attributes (read-only, hidden, system,
archive), and unix permissions. It's not finalized though
as there are some major concerns:
1. Although the use of variable entry sizes conserves memory,
a single corrupt entry could crash the entire filesystem.
2. The use of FAT's 'cluster header' probably isn't the best
way to locate fragmented data, but I don't really want to
to use inodes because it requires more memory.
I'm still working on it, but when it's finalized I'll be sure to
post documentation as well as any utilities I might make.

* Wrote a memory map for RAM

* Wrote a bootloader for a FAT12 floppy that boots KERNEL.BIN
at 0x00010000

* Wrote drivers for FAT12, FAT16, and FAT32 filesystems (although
changes will have to be made since it's 16-bit code)

* Enabled Vesa

* Enabled the A20 Line

* Setup the GDT

* Entered 32-bit Protected Mode

During my 'break' time I draw concepts for the GUI and work on my other
project, ZeldaFD (not that you'd really care to hear about it). My main
focus now is writing drivers, standard libraries (malloc, stdio, stdlib,
dirent), and a decent gui framework.


PS. I'm not actually gonna call this project SmileyOS, that was just a pun

(Slightly offtopic from what this thread has came to, but relevant to the first few posts)

At the risk of making people explode: If you want to make a widget on the desktop it's pretty easy.

Step 1: Create your window with whatever you want on it like a standalone window (transparency key, no border, click to drag, etc... to make it look good as a widget)

Step 2: Set your window as a child of Explorer. Here's how to do it in C++. It requires windows.h in C++. There are equivalents for these functions in VB, C# and others.

Code:


Step 3: ???

Step 4: Profit!


Here's code for VB that does it, too (Complete program):

Code:

Thanks for the info, but I already knew about that. My main issue was trying to render to the desktop without using a transparency key. (because I don't always know what I'll be rendering and lighting alone can cause a single color to vary into hundreds of shades)

But as I tried to say before, that was just what gave me the idea to start this project. This project isn't intended in any way to solve the problem. Ben said something to me last time I was online about using layered windows and I think I just figured out what he meant.
* Have two windows rendering the same scene overlap
*One window should have a key transparency of pure red and the other pure green
Since they overlap, all colors would be visible.

That wasn't what I meant at all, but that's an ingenious solution to the problem that I hadn't thought of. Layered windows is the name given to a particular window style in Windows for keyed transparency or whole-window translucency.