MenuetOS 1.23.60 released

[x64]

Recent additions include SMP support for upto 32 processors and 32GB of ram, support for time-critical, non-preempting processes, additions to window transparency, improved usb webcam and storage support, context-mixing compressor, WebCall (IP to IP with audio and video), Streaming audio (Internet radio) and video support, all written 100% in 64bit x86 assembly.

http://www.menuetos.net

[Ycep]

Cool!
I can't believe that one could create such advanced and successful OS written entirely in fllat assembler.
I'm suprised that your OS supports Serbian language. Why?
Seems that wikipedia MenuetOS page needs to be updated.

[BrightLight]

I've not tried this release, but I'll assume it's impressive just as all the others I've tried.
One of my inspirations to write my OS entirely in assembly language was Menuet, by the way.

[MichaelFarthing]

This is uplifting. I've felt quite exposed on here with all this talk of C and the disadvantages of assembler. Glad I'm not alone!

To my mind programming in a high level language takes you away from what is going on and half your OS has really been coded by someone else. Added to that there is the wasted time with all those innumerable compiler directives that consistently throw problems at you. At least my problems are all of my own making, which speeds up the process of resolving them quite considerably.

It does require (self-)discipline in that to avoid a spaghetti mess it is helpful to have principles of coding, conventions of register use, and a readiness for that boring concept of documentation. But if you have those in place you will be streets ahead of the C men, who undoubtedely won't have done this..*

*Some of them take a pride in not doing. One of the first C books I encountered had a 'helpful' table of indirection interpretations with the C syntax and helpul translations such as:

"Pointer to an array of pointers to functions returning arrays of pointers to arrays of functions".

I used that ever so often

[onlyonemac]

"Pointer to an array of pointers to functions returning arrays of pointers to arrays of functions".

I used that ever so often

There's no such thing as an array of functions in C. But a pointer to an array of pointers to functions returning arrays of pointers to functions? Suppose your driver architecture involves each driver having a function to return an array of pointers to the various functions in the driver (note: bad driver architecture) - that's a function returning an array of pointers to functions. Let's call this function "getFunctionPointers()". Now we'll have an array containing a pointer to each driver's "getFunctionPointers()" function so that we can get its function pointers whenever we need to call one of its functions (note: should store them locally to avoid a redundant call into the driver each time) - that's an array of pointers to functions returning arrays of pointers to functions. Then we want to pass this array to another part of our kernel, and the simplest way would be to pass a pointer to it (note: should make kernel more modular) - that's a pointer to an array of pointers to functions returning arrays of pointers to functions. (Just messing around lol.)

[MichaelFarthing]

There's no such thing as an array of functions in C.

The book went on to concede (as I recall) 'Even experienced C programmers can occasionally get confused'

I cite that as my defence.

[jojo]

Pointers, arrays, function pointers, and compositions thereof, to be clear, have zero to do in particular with C. You have to deal with that stuff just as much in assembly, and in the context of assembly you don't have nice(r) idiomatic typing tools to help you wrangle them, so I'd argue that handling an array of function pointer pointers returning arrays of function pointer pointers would be an even more difficult construct to manage in assembly (though to me, and I feel like to you as well, that's kind of the point and fun of the exercise).

Regardless, I sincerely appreciate the endeavor of writing in assembly (we're here to let our programming freak flag fly, right?), so definitely don't construe this as me being critical.

[MichaelFarthing]

Regardless, I sincerely appreciate the endeavor of writing in assembly (we're here to let our programming freak flag fly, right?), so definitely don't construe this as me being critical.

I didn't take any offence from you (nor, indeed, from onlyonemac's delightful post).

My venture into this arena is purely for fun and I have set myself a (seemingly) ridiculous task. I have often mused on how the first computers ever got off the ground in much the same way as how DNA ever first got its act together to replicate itself (and being told it was actually RNA that did the job first does not diminish the achievement of whatever molecule it was).

So.. I have allowed myself 512 bytes of hand-coding that I have dumped into the first cluster of a hard disk partition. I also allowed myself to use grub to chainload that cluster. My aim was then to develop everything entirely from those 512 bytes - no assembler, no compiler. The 512 bytes gave me the ability to load a larger block of data from my partition, display it on screen as a series of hex-represented bytes, navigate and edit those bytes and save them back again. What's more, I had three bytes spare. I now have an assembler, disassembler, text editor and an elementary file system that enables me to store documentation in my partition and gives me a backup boot option for when I mess up. There have been just a few occasions (surprisingly few as it happens) when I have had to cheat and use external tools to doctor a few mis-written bytes in my private partition, but once I had taken the precaution of keeping two independently bootable versions I haven't had to do that. I don't recommend it, but it has been (and continues to be) a lot of fun and a satisfying thing to do.

[onlyonemac]

There's no such thing as an array of functions in C.

The book went on to concede (as I recall) 'Even experienced C programmers can occasionally get confused'

I cite that as my defence.

All I'm saying is, you didn't look that up in the book.

Also, I remember a website and equivalent Linux command-line utility to give a formal definition of a C type based on it's declaration as it would appear in code (so you could type in "char* character" and it would say "character is a pointer to a value of type char" or something like that). I think it could also do the reverse (to some extent, if you were exact with your wording) so you could type in "character is a pointer to a value of type char" and it would output "char* character" to give you the correct way to declare what you've requested. Unfortunately I can't remember what it's called.

[Octocontrabass]

It's cdecl.org.

[onlyonemac]

It's cdecl.org.

Thanks. Yes, there is a Linux version available as well. I had it installed before I upgraded to Ubuntu 16.04 and was quite useful (but evidently not useful enough for me to have needed to install it again yet lol - I think at the time I was trying to sort out a particularly complicated section of code and needed a quick way to easily determine exactly what type of variable I was dealing with).

[MichaelFarthing]

There's no such thing as an array of functions in C.

The book went on to concede (as I recall) 'Even experienced C programmers can occasionally get confused'

I cite that as my defence.

All I'm saying is, you didn't look that up in the book.


.

Fair cop, guv. I should have put in a 'such as' and it probably didn't do pointers to functions. Got carried away.