Index
> MenuetOS > criticismGoto page Previous 1, 2, 3, 4, 5 Next |
| Author |
|
|
daneel 25 Jan 2005, 14:20
What about a UNICODE font ?
|
|||
25 Jan 2005, 14:20 |
|
|
Madis731 25 Jan 2005, 15:38
It's being worked on - just like browser
|
|||
|
25 Jan 2005, 15:38 |
|
|
luka666 25 Jan 2005, 15:44
you can get unicode here . somebody has to include it into the kernel....
|
|||
|
25 Jan 2005, 15:44 |
|
|
Adam Kachwalla 25 Apr 2006, 00:01
Well... MenuetOS was written in ASM ONLY: All the others use C. ASM is a little harder to work with, but the result is powerful. MenuetOS fits on a floppy, and another OS with all the features, written in C, would be bloated up.
|
|||
|
25 Apr 2006, 00:01 |
|
|
f0dder 25 Apr 2006, 10:18
Quote:
And what exactly do you base that opinion on?  |
|||
|
25 Apr 2006, 10:18 |
|
|
Borsuc 25 Apr 2006, 14:30
f0dder wrote: And what exactly do you base that opinion on? C programs aren't necessary that bloated up, since I code some of my testing programs to check my ideas if they work. What makes C bloated is the damn standard library -- printf for example is overbloated in implementation (I checked it), and 90% of the time, it introduces features you don't even use! What I REALLY love about asm is that it can do nice tricks, and you can understand low-level internals with it (it gives more knowledge and experience about the computer than C). For me, even if asm saves off 15 bytes more than the C version, I still choose it (well, there may be some other 'situations', but I'm talking generally). And low-level tricks and algorithms are a much interesting intellectual challenge, and i like that
and by the way -- C was designed to be a standard. That is, it doesn't expose computer-specific features.  |
|||
|
25 Apr 2006, 14:30 |
|
|
f0dder 25 Apr 2006, 17:10
Quote:
That's a problem with how printf works - format strings and all. It's a bit hard knowing at compile/link time which features will be used, so it's all linked in. If you don't need the complexity of printf, use puts instead. And, well, the libc isn't too bad really... a hello.exe with no tricks and msvc libc is 28kb. You'll have to go many CPU architectures back before this would pose a serious problem. And of course, the libc is a one-time "bloat" - once you actually start using the libc, the amount of wasted bytes go down drastically. If you don't use the libc, well, the don't include it in your programs. Or, use a libc replacement... with Jibz' WCRT, the simple hello.exe goes down to 3.072 bytes. So much for bloat
OF course the language to choose depends on your needs and what you feel good about. Skipping C/C++ because of "bloat" is a silly misinformed choice, though. |
|||
|
25 Apr 2006, 17:10 |
|
|
rugxulo 26 Apr 2006, 22:26
There are so many languages to work with, it's almost ridiculous. Choose wisely, but don't limit yourself to just one or two! Whatever makes you comfortable, use it. But, strive to write small, fast, portable, useful, clean, commented (or at least easily-licensed) code. Oh, and have fun! Otherwise, why waste your time?
 |
|||
|
26 Apr 2006, 22:26 |
|
|
gunblade 27 Apr 2006, 12:01
f0dder, those hello world examples are still big.. even with the shrunk libc you were talking about, 3kb for a hello world is quite big, even for windows.
Yes, it doesnt seem like a lot, its only 3kb, but if your trying to pack as much functionality into an OS, and that OS runs from a floppy, size matters. Not only that, it will means less memory usage. Another thing with C; the compiler always creates extraneous instructions. A compiler isnt a human, it doesnt know whether a certain register actually needs to be stored or not. Therefore it might push a register when it doesnt need to. Compile a program into assembly and its easy to see how many unneeded operations there are. Oh, and most C compilers will take up much more space than fasm. But it could be worse.. It could be Ada 
(Sorry to anyone who likes ada, but im being forced to use it for my course in university, so i have a bad opinion about it. Next year you'll hear me complain about Java )
One final comment. It's a shame that menuet32 died off (as far as i can tell). It was designed as an OS which is suppose to support old hardware (which is why they didnt implement SSE and such), but now only the 64bit version is still in development, its a shame  (although i seen the screenshots of the latest menuet64, and its looking really nice. Well done) |
|||
|
27 Apr 2006, 12:01 |
|
|
f0dder 27 Apr 2006, 12:22
Quote:
If you're writing a OS you're not including libc... and as for 3kb, that's *including* parts libc which gives you quite a lot of code to play with. Without libc, with proper sections and 512byte alignment, no merging tricks, no dirtyness of any kind, you get a 2kb executable. If you think this is "bad" or "bloat", you need to get a life
Quote:
If you use a retarded compiler, or turn optimizations off when compiling, the code will be pretty bad. But use a modern compiler, especially one with global optimizations and link-time code generation, and the results are pretty good. Sure, you can often handwrite things better, but most of the time: it's not worth the effort. |
|||
|
27 Apr 2006, 12:22 |
|
|
bogdanontanu 27 Apr 2006, 16:38
Gunblade,
SolarOS is still under active development, it is 32bits and works on older computers
http://www.oby.ro/ |
|||
|
27 Apr 2006, 16:38 |
|
|
profkid13 29 Apr 2006, 17:48
active development?
last update was on 2005-03-01 ! |
|||
|
29 Apr 2006, 17:48 |
|
|
okasvi 29 Apr 2006, 22:02
profkid13 wrote: active development? for some ppl quality comes before quantity Quote: 2006-03-15 - Work in progress: _________________ When We Ride On Our Enemies support reverse smileys |: |
|||
|
29 Apr 2006, 22:02 |
|
|
Borsuc 01 May 2006, 11:29
f0dder wrote: OF course the language to choose depends on your needs and what you feel good about. Skipping C/C++ because of "bloat" is a silly misinformed choice, though.
And besides: C has bloat. If you're talking about BIG bloat, then you're probably right that it doesn't insert any bloat. But I'm from the view "small things should not be taken lightly". And I'm NOT the guy who thinks "better performance" means "wasting resources". From my view, faster and more powerful computers are not an excuse for me to get lazy and write junk code. We're not in 1979, but that doesn't mean today that JUNK is acceptable just because computers are faster. (ok, don't get me wrong, C is my choice HLL, but I wasn't even complaining about C, I was complaining about phrases like "we're not in 1979, let's get lazy and waste resources") Plus, C++ is VERY bloated. That's NOT because the compiler is stupid or because of the standard library, that's because of HOW YOU DESIGN your code. If you design it with objects, the compiler will optimize objects, but the design will remain unchanged. Therefore, I've seen a lot of projects that could've been designed without objects to improve performance. So in HLLs, it's not a question of how powerful the compiler is, it's a question of how you design your code. That's what makes hand-written assembly better -- when you design in asm, you usually think in every low-level possible form, and design it differently than you would with a HLL. Trust me, I've had experience. I don't like very abstracted HLLs like C++. f0dder wrote: Sure, you can often handwrite things better, but most of the time: it's not worth the effort. "you can often handwrite"... why often? I'd say always. Like I said, it's not a matter of how powerful the optimizing compiler optimizes your algorithms and design, it's a matter of how you design your code -- in asm, you usually design it differently than in HLLs. Of course, non-experts won't probably design in asm better, but by practice they will in time. No matter how powerful the compiler is, it will still optimize YOUR design/algorithms. In asm, you have different designs. No matter how hard you improve something, there will be a better solution, even if it demands a TOTAL rewrite of the whole design's structure. besides, the argument "optimizing compilers will probably do a better job than handwrite" is ridiculous. Just imagine yourself looking at the output of a compiler and improve that. So much for that argument |
|||
|
01 May 2006, 11:29 |
|
|
f0dder 01 May 2006, 12:29
Most of the time, I code to "get things done". Not necessarily for profit, but still because I have a need for a tool. I am for good performance (and even for small size, silly as I am
 ), but I really can't be arsed to handwrite things in assembly unless there are some very tangible benefits from doing so.
The slowest test computer I have is a 350MHz Pentium2 with MMX and 64meg ram, and I try to make sure all my stuff runs reasonably on that machine (this means "runs well" in most cases, unless there's some heavy calculations involved). I think it's fair enough to have a machine like that as minimum specs in 2006. On such a machine, a ~100kb executable is *nothing*. Even on a puny 4gig harddrive, such an executable is 0.0024% of the total disk space, and thus "bloat" seems like a wrong word
Quote:
That certainly depends on HOW you design your code. My bin2o (binary file -> ms coff) program is written in C++ with classes and everything, but the executable is still only 4kb. Yes, it could be done smaller in assembly etc yadda yadda, but what's the point? Even when dealing with full class hierarchies, your don't necessarily get explosive code bloat if you know what you're doing. I put stability and maintanability over size and efficiency... but I still value size and efficiency a lot. I just find some statements on "bloat" to be very ludicruous. Quote:
Sometimes theres one optimal solution, and sometimes the compiler will choose that. Other times, the one optimal (or few near-optimal) solutions will only be marginally better than a "good" solution, but will require an disproportinonate amount of time to design. Even though most of my programs are done for fun, I still value my time. But even if I've grown "old and lazy" and mostly use assembly "where there's a need", I also sometimes write assembly just for fun - it's just not my main language since I left the 32bit DOS days and my 486. |
|||
|
01 May 2006, 12:29 |
|
|
Borsuc 01 May 2006, 13:08
f0dder wrote: Most of the time, I code to "get things done". Not necessarily for profit, but still because I have a need for a tool. I am for good performance (and even for small size, silly as I am
f0dder wrote: The slowest test computer I have is a 350MHz Pentium2 with MMX and 64meg ram, and I try to make sure all my stuff runs reasonably on that machine (this means "runs well" in most cases, unless there's some heavy calculations involved). I think it's fair enough to have a machine like that as minimum specs in 2006. . But the fact was that I appreciate even non-noticeable things, no matter of the power of the CPU, because that things are STILL done internally, just that with a 3Ghz processor they are done faster than on a 1Mhz one, but they are STILL done inside. And my point was that I appreciate them (for some of my projects, of course, not all of them). I was merely explaining my view, I have nothing against your opinions as well.
f0dder wrote: On such a machine, a ~100kb executable is *nothing*. Even on a puny 4gig harddrive, such an executable is 0.0024% of the total disk space, and thus "bloat" seems like a wrong word
f0dder wrote: Sometimes theres one optimal solution, and sometimes the compiler will choose that. Other times, the one optimal (or few near-optimal) solutions will only be marginally better than a "good" solution, but will require an disproportinonate amount of time to design. Even though most of my programs are done for fun, I still value my time.
Asm takes more time, but the argument "optimizing compilers will probably do a better job than handwrite" is false. My saying was that "redesigning" your code so it is improved will always be possible, but it will certainly require more time to do it. What I wanted to say was that it matters how you design your code, and in asm you usually design it better (if you know asm well, of course). But that doesn't mean it doesn't take more time. f0dder wrote: But even if I've grown "old and lazy" and mostly use assembly "where there's a need", I also sometimes write assembly just for fun - it's just not my main language since I left the 32bit DOS days and my 486.
besides, I'm also a bit lazy sometimes, especially for annoying tools (which I don't release anyway, since they're very specific to my machine and customizations, etc.. and there's no point. I just write them because I'm annoyed sometimes from doing the same thing again and again). Lazyness is a human flaw and we all have it |
|||
|
01 May 2006, 13:08 |
|
|
f0dder 01 May 2006, 13:24
Quote:
That depends, really
It takes some experience to beat a decent compiler, and usually you won't "super-hand-optimize" your entire program. From the assembly code I see a lot of people writing (here, asmcommunity, masmforum, newsgroups), even mediocre C code would end up with better machine code. That's the observation I base the above statement on. And well, I do appreciate internals - one day I just realized that I tended to get lost in the details instead of getting work done. So when writing something like http://fSekrit.donationcoder.com , I was (relatively) lazy - but the end result is still pretty tiny, especially compared to the other similar products around (like Steganos LockNote). |
|||
|
01 May 2006, 13:24 |
|
|
Borsuc 01 May 2006, 13:40
f0dder wrote: That depends, really so you're always gonna beat it this way |
|||
|
01 May 2006, 13:40 |
|
|
f0dder 01 May 2006, 15:02
True - that does lower the barrier a bit. (But there's still those *rare* times where the compiler generates optimal output
).
I find that looking at compiler output often leads to sub-optimal code, because you lock yourself into the compiler way of thinking... |
|||
|
01 May 2006, 15:02 |
|
| Goto page Previous 1, 2, 3, 4, 5 Next < Last Thread | Next Thread > |
Forum Rules:
|