OSDev.org

Troy, my post detailed in not so polite ways that it seems the number of characters between the first 'k' after the command prompt and the single-quote is exactly 255. I'll leave you to tell what that exactly means.

I took a quick look at the code of your OS, but I haven't tried it yet.

One thing though - why do you have backup files (ones ending with ~ characters, eg. something.c~) and object files in your SVN? It's a lot cleaner to leave these out imo.

*glares at GEdit and his makefile*

Thanks for all the (mostly) positive replies! TBOS32 0.1.1 is taking a little bit more time than expected, as I have the second half of my final exams today. I bet I could have the bugfixes done tonight. Most of the warnings have been taken care of.

@Steve: I'm not using the SVN anymore. <flameguard>

Troy Martin wrote:

earlz wrote:I don't like having a sudo in regular 'make' (and I don't use Linux, so it doesn't even work for me.)

num-lock doesn't work.(like I can't use the number pad for numbers)

other than that. Nice work

Thanks! Yeah, num and caps support haven't been done up yet.

No sudo? Whoa... Well, it's needed for losetup and mount, unfortunately.

It's kind of odd to make someone use sudo to just compile it. I would separate the compilation and image creation in the makefile. i.e. "make" compiles, but "make test" compiles and tests, and requires sudo/losetup/etc. Then once you want to compile and use it in a real system, you won't have to modify things to remove/bypass the test scripts. I also have a "sudo make install", which puts my OS in my laptop's boot menu, if I'm feeling confident.

Edit: fixed screwed up quoting

so........... troy how 0.1.1 coming?

i think when i go 16 bit protected mode or 32 i might use C and not asm. (i am not really good at pmode in asm)
i can go into pmode using asm, but i have problems understanding somethings(not going into pmode) but doing things in pmode(something i cant do) but i can try learning i asm first, if nothing works, i might skip C and stay in real mode

GhostXoPCorp wrote:so........... troy how 0.1.1 coming?

Pretty good so far, I have about an hour to work on it before going back to school for my science final..

Real mode is limiting; I'd suggest against it for any serious OS work.

pmode really worth the work? i mean i just got the feel for rmode. as for real mode, i could just try and construct a memory manager for accessing not just 640k of memory. but alittle more.

Protected mode is definitely worth it. Not only is it protected (hehe) but you can fine-tune drivers because they're your own creation and not part of the BIOS. You, the kernel developer, have the ultimate control over the entire 32-bit x86 platform.

Announcement: 0.1.1 is out with bugs fixed as per Ghost's and Blue's reports! Thanks guys! The object and backup files have also been removed, and the initrd has a more sensible file list (woot for changelogs, hehe.)

Troy Martin wrote:Protected mode is definitely worth it. Not only is it protected (hehe) but you can fine-tune drivers because they're your own creation and not part of the BIOS. You, the kernel developer, have the ultimate control over the entire 32-bit x86 platform.

Announcement: 0.1.1 is out with bugs fixed as per Ghost's and Blue's reports! Thanks guys! The object and backup files have also been removed, and the initrd has a more sensible file list (woot for changelogs, hehe.)

Did you actually fix the buffer overflow yet?

Should be fixed as a byproduct of my primary bugfix in get_string.

Troy Martin wrote:Should be fixed as a byproduct of my primary bugfix in get_string.

Please tell me that get_string is something in user space. If you have buffer overflows like that in kernel space I refuse to look at anything you produce, ever again.

syntropy wrote:

Troy Martin wrote:Should be fixed as a byproduct of my primary bugfix in get_string.

Please tell me that get_string is something in user space. If you have buffer overflows like that in kernel space I refuse to look at anything you produce, ever again.

I doubt he intends to have the real shell running in kernelspace (hopefully), so it's not like it matters if it gets buffer overflows. I think anyone reserves the right to write crappy test programs during initial development. Why are you so grumpy today? I thought you already had your coffee .

NickJohnson wrote:

syntropy wrote:

Troy Martin wrote:Should be fixed as a byproduct of my primary bugfix in get_string.

Please tell me that get_string is something in user space. If you have buffer overflows like that in kernel space I refuse to look at anything you produce, ever again.

I doubt he intends to have the real shell running in kernelspace (hopefully), so it's not like it matters if it gets buffer overflows. I think anyone reserves the right to write crappy test programs during initial development. Why are you so grumpy today? I thought you already had your coffee .

See the tacos thread.

NickJohnson wrote:

syntropy wrote:

Troy Martin wrote:Should be fixed as a byproduct of my primary bugfix in get_string.

Please tell me that get_string is something in user space. If you have buffer overflows like that in kernel space I refuse to look at anything you produce, ever again.

I doubt he intends to have the real shell running in kernelspace (hopefully), so it's not like it matters if it gets buffer overflows. I think anyone reserves the right to write crappy test programs during initial development. Why are you so grumpy today? I thought you already had your coffee .

Exactly. mush is designed to be a fallback shell, in case whichever program that has been specified as the shell cannot be found by the kernel.