OSDev.org

Hi,

DevL wrote:Don't feel slammed - I just wanted to point out that standards exist for a reason and they should be embraced rather than everyone reinventing the wheel.

I agree, standards are good - there's so many to choose from and if you don't like any of them you can create your own .

There are disadvantages though. Obvious disadvantages would include performance and consistancy. Less obvious disadvantages are marketting and progress.

For example, POSIX is a standard that defines how an OS "should" behave. If we all followed POSIX then there'd be no point trying to design a new OS in the first place, and OS's that use techniques that are far better than those advocated by POSIX would never exist. If you're trying to get people to use your OS, then saying it's the same as everything else isn't going to work. Being able to say your OS is better than the standard stuff (and provide reasons) is a far better approach IMHO.

In general standards are a set of restrictions that limit an OS designer's options (while also limiting the amount of work needed for design, and the amount of work & learning needed by those who use and/or develop software for the OS).


Cheers,

Brendan

Cheers, DevL! Long time no see on this board!

I don't advocate against using select(), but I always point out that people stopped coding C and started coding POSIX. It's like coding Win32, only that POSIX coders usually don't realize when they crossed the border.

Brendan wrote: For example, POSIX is a standard that defines how an OS "should" behave.

A quite common misconception. POSIX is how a Unix "should" behave. Nothing more, nothing less. Some people - coincidentially from the Unix camp - consider it some "uber-standard" that every OS should follow, but I'm not one of them. In fact, POSIX being a compromise designed by committee, I consider it a nice collection of serious thinko's and legacies.

Unfortunately, the hype around GNU/Linux makes every OS that doesn't come with POSIX compatibility even more of an outsider. "You can't even compile vim on that thing!" Yeah, as if it were that much of a drawback...

Being able to say your OS is better than the standard stuff (and provide reasons) is a far better approach IMHO.

I would wholeheartedly agree with you, if not most hobbyist coders had been turned into a crowd of fanboys that asks whether your OS can run Apache and Mozilla...

In general standards are a set of restrictions that limit an OS designer's options...

Depends. You have to be aware of the existing standards, and make conscious decisions whether to use them, extend them, or avoid them. (That was the reason I pointed out the non-ANSI-ness of select() above.)

Of course there are better ways for memory handling than malloc(), and I would expect an OS to provide them, under a name that makes it clear it ain't C but OS-API. (AllocMem(), anyone?) I still expect the OS to provide malloc(), too, because it's a basic standard.

select(), on the other hand, is a POSIX thing. Either you are striving for POSIX compatibility, then I expect you to go all the way - or you avoid it consciously, then please don't make your function a look-alike of a POSIX one since people will then expect the rest of POSIX to work, too.

That's one of the major drawbacks I see in POSIX: They made their calls virtually undistinguishable from ANSI C calls, so that the people from POSIX systems just assume their API to be omnipresent.

And are quite surprised when being told that POSIX doesn't even get leap years right...

Personally, I'm basing everything around things that I think would work and loads of hacks. I dunno why I like using hacks in my stuff (though it may be the mystique of having lots of weird code that does weird stuff, well) but I find they're efficent. Standards can be the drool of major corps. but they're also usefull. For example: ext2/3 is regonized by most linux buffs and such as a efficent fs. If you want, you can support some standards and reject others. Example: I HATE NTFS!!!!!!

Cheers, DH.

Dragon_Hilord wrote: Personally, I'm basing everything around things that I think would work and loads of hacks. I dunno why I like using hacks in my stuff (though it may be the mystique of having lots of weird code that does weird stuff, well) but I find they're efficent.

Development experience learns you ways to avoid hacks but to achieve the same sort of performance with maintainable code. Then again, sometimes you can very well explain why it isn't possible to make an efficient equivalent solution.

Standards can be the drool of major corps. but they're also usefull. For example: ext2/3 is regonized by most linux buffs and such as a efficent fs. If you want, you can support some standards and reject others. Example: I HATE NTFS!!!!!!

Why do you hate NTFS?

I dislike NTFS because it is closed by Microsoft and hence not implementable with a guarantee that it won't be changed overnight to something very incompatible. Hence, I ignore NTFS as something to support (yes I know, this is not going to raise my user base, but it's up to 3-4 I think already so that's like 300% more than I expected & aimed for). Don't disregard its design however. The designers did a quite nice job and all documentation and ideas you can get out of it are always welcome. For instance, NTFS uses extents and inodes. Ext2 uses indirect blocks (iirc) and inodes. Extents are a lot more flexible to use in terms of disk access and they take one hell of a lot less space. In terms of speed they might be slower, but since the main slowdown of current computers is the disk & memory access speed, it is very unlikely that this is in any way a problem.

Don't just say it's bad because you can't get it. Don't have a childrens attitude, be grown up & respect that they did quite a nice job on it or admit you didn't see it.