OSDev.org

I've been thinking recently about window systems, since I want to write one for my college thesis.

Now, I've actually got a fairly good idea going based on Plan 9-style file-servers and an old bit of Scheme research called Functional Postscript. But that's not what this is about.

My initial design forced the user to specify programs in Scheme to perform the functions of handling input to the window and creating the Postscript picture that the windowing system would later draw on the screen (after translation and clipping). Each of these Scheme programs would run in their own Scheme environment in their own thread. The idea was that an application's window should not appear to hang just because the application itself has become CPU-bound. The window would communicate with the main application process/thread via message passing and messages from the application would take the same form as input events from the window manager (received messages).

Later on I ditched the full Scheme system for being excessive and unattractive to programmers. This left me with a more elegant design that allows pictures to be computed by any programming language.

However, the new design does not enforce multithreading like the old one. It relies on the application developer to separate the main application from the window processing, because the window system merely provides certain files in the namespace of a process instead of running its own process or thread.

Which brings us to our design issue. I could modify the current design to force application developers to use multi-threading by either specifying windows as Scheme/FPS programs again, or by having each window run a process that links to an application-given shared library and runs a routine in the library. Either of these would keep the fetching of window-system input events via Plan 9-style multiplexed design files and would also leave IPC between the window and the main application entirely up to those two processes. Finally, forcing multi-threading would improve user experience by making applications more responsive and improve performance by taking advantage of multi-core processors.

But I somehow think that programmers, most of whom prefer to shoot themselves in the foot by writing messy C++ than to onerously, tediously, painfully write a typecast in Object Pascal, would despise it. They would want their freedom to write bad software that users would complain about. Or they want their freedom to implement their own custom multithreading libraries, because me, Bell Labs, and Linux developers are all self-evidently too bloody stupid to design or implement a really proper multi-threading library.

This would result in a proliferation of mutually incompatible GUI toolkits with their own concurrency models, making the user's experience suffer. On the other hand, the freedom to suck would make the windowing system a much more attractive and indeed, flexible, platform.

So who should hold more sway over our system designs? The developers who will build on top of our systems or the end users who will actually use them? Put developers in bondage to improve the end result, or trust their self-discipline?

I would much rather write a load of code in beautiful, organized, do-stuff-the-way-I-want-it-not-the-way-the-language-allows-me C++ rather than do-as-we-say keywords-in-order Object Pascal.It just has too many requirements which only force you to do something or to get an error, not having any functional reason behind them.



I say neither.

If you do the former, you won't get programmers (or barely any) since you force them to conform. If you do the latter, you will get loads of crappy programmers who will make programs that hang.

My suggestion is, make a cross-language (preferably) framework that allows you to create a proper application in all of the supported languages more easily than any supported framework allows you to make crappy applications. Advertise it, tell people about it, give it a "mark of quality" if the program is written in that style (and check it, don't just make it a free one).

This sounds to me very much like one of the basic problems in Windoze. The main() routine needs to have a specialized form, but in the M$ case, they don't just give it to you.

Development programmers don't want to spend hours creating a functioning interface between their app and the OS. They want a template, they want it to be guaranteed to work, and then they want to reuse it forever in all their apps. In Windoze, the most convenient thing to do is use Petzold's template, generally.

So, I'd think that in your case, what you would want to do is provide developers with templates in many languages, of a basic main() function -- created the "proper" way. Then developers can skip to the parts they want to deal with -- creating the user interface, and dumping the functional parts of the code into the places they belong in the template.
If you make it that brainless for them, they will do it your way, I'm convinced.

But I would definitely come down on the side of:
it is the USER who owns the machine your OS is running on, and it is the USER who "bought" your OS in whatever fashion, and it is the USER who paid good money for the developer's app. So make the OS work damned good for the user, and screw the developer (if necessary).

That doesn't get you any developers, hence no users.

/business/: s/easiest/most productive/

The easy way is not the way that gives you the best result - playing games at work won't get you a better product. If you have a business argument, you will win the end result, be it because it's easier to use or because it'll give you more sales (thereby decreasing NRE and increasing ROI)

For hobby programmers, make it the easiest.

I was more thinking about, employing automatic source-code reformatters and style-checkers instead of hitting every programmer over the head with a 100-page style guide document.

Or, in regard to the OP, make it easier to write good software than to write bad one. (In layman's terms this is usually called "API design".)

I haven't met the first source code formatter or style checker that corrected bad assumptions and bad design. Mostly they correct that which most people argue about, not that which most people do wrong structurally.

It occurred to me that we're looking at a dichotomy between two ways of writing software: The Apple Way and The Unix Way.

The Apple Way is about making great software for the end user, even if it means being a Nazi to your developers. The Apple Way told Apple not to pay Valve a measely $1,000,000 to port the Orange Box to OSX, even though it would make OSX far more appealing to gamers.

The Unix Way is about providing developers with an API that they can extend and build upon with the utmost ease, resulting in a total lack of standardization and continually dissatisfied users because there's always something that doesn't work (because no hacker finds it interesting enough to fix).

Of course, the Windoze Way is to promise the advantages of both of the above with none of the drawbacks, then slowly scale back your feature-set and allow buggier code as the release date gets nearer. Finally, deliver a piece of crap that totally fails to fulfill your promises because you absolutely, positively needed to maintain backwards compatibility with other people's mistakes.

For my personal project, application coders will write their interface code in whatever language they like, then compile it to a shared library that gets loaded and jumped into by an extremely lightweight window-system process responsible solely for examining the window's running environment and passing information about that to the shared library.

The idea is to make it convenient to write your windowing code separately from your application code without actually forcing it.

But by all means, let's keep at our dichotomy. I don't even feel sure that my middle path is the correct way out of this issue.

Exactly. So isn't it a good thing to have the arguing out of the way so you can focus on design and semantics instead of the One True Brace Style?

Crazed123 brought it to a good point, but I feel he didn't nail the Unix "problem" correctly. It's the fact that too many Unix'ers only care about a problem being fixed, not about it being fixed with some elegance (or some sustainability). Not being a pro at a subject is grounds enough for them to sneer at your inability to find your way through dozens of command line options, telling you to "use Windows if you want one-click solutions".

The excellent middle way, for me, was AmigaOS. Great developer community, with very high standards as to usability even for the layman. Too bad its ideals got minced between corporate Windows and hackish Linux.

Ah, right, The Amiga Way: right really fucking good software that's also really hackable, because if you don't it will crash the computer.

OK, let's drop all the wishful thinking, then. Not one of our OSes is going to lure a developer to write an app for it, for the semi-long-term forseeable future. Any apps that get ported to our OSes are going to end up there because either we do it ourselves, or there is a nearly 100% automated system for doing the port. Either a cross compiler, or some really trivial cut/paste mechanism to copy source code written for one of the above OS platforms onto yours. It does not matter how complex it is for "developers" to write apps directly for your OS. There won't be any. What you need to be able to do is write your cross-compiler so that it can implement all that complexity internally, during the automated porting process. If you can't do that, then it ain't gonna work anyway.

Pessimistic thinking like that tends to become a self-fulfilling prophecy.

I think you're confusing the Apple Business Way with the Apple Development Way. The Apple Business Way says that they're too busy pursuing high profit margins with the iPhone to bother trying to break into the PC gaming market in a bigger way. Wait a few years, maybe it will still happen.

The Apple Development Way is something I'm admittedly just getting into myself, but it seems to me to fit Solar's suggestion to make things easiest. I think it's a sort of middle ground between "bondage" and "discipline":

• GUI app development in C or C++ is discouraged in favour of Objective-C, since the Cocoa APIs (based around the old NextStep frameworks) are implemented in Objective-C.
• Objective-C is a superset of C, so chalk one up for "discipline" over "bondage".... You can still do evil things with pointers if you want.
• Objective-C's OO features are based on Smalltalk. They are way easier to learn quickly and use effectively than the plethora of OO features in C++. Easier to learn IMO means harder to abuse. For example, when designing a class in C++, a freshly-graduated wet-behind-the-ears junior programmer has to decide 1.) Whether it should typically be allocated on the stack or heap, or be flexible so it could be either. 2.) Whether it should be copyable or not. 3.) Whether it should use operator overloading. 4.) Which methods should be virtual, which methods should be const, which arguments to those methods should be const, etc. 5.) Whether to use multiple inheritance, single inheritance with delegation, or something more exotic like template-based mixins or the "curiously-recurring template pattern". You get the idea... I've learned the hard way that most people who haven't been using C++ for at least five to seven years will frequently get many of these decisions wrong for a given set of circumstances.
• The NextStep APIs that Cocoa is based on are almost 18 years old, and from what I've seen, the core APIs haven't changed much in that time. They were way ahead of their time back then, and are still useful, flexible, and easy to use now.
• There is a bit of "bondage" in the way that Xcode forces you into the MVC pattern for GUI development, but IMO this is a good thing.
• Despite all my blather about Cocoa, you can still develop good old C or C++ apps that run at the command-line or work with X-Windows (OS X has a kinda-ok built-in X server), if you really want to.

If you want an interesting take on Cocoa versus another relatively modern set of APIs for application development (.NET), see this guy's blog. It makes for an interesting read. My take on it is that Apple spends as much time on API usability as it does on UI usability. I wrote a series of white papers on the application of general usability and human factors principles on API design, but sadly they're the confidential property of a large software company that I cannot name. I guess you'll have to take my word for it.

Because you can't improve on perfection.