Hacker News new | past | comments | ask | show | jobs | submit login

> They were not used in apps with complex UIs because native controls were hard to skin

Every time I’m forced to use Windows I’m blow away by the clownishness of every application deciding to skin its own custom windowing controls.

This started happening some time around XP, I think?




It definitely started before: one of the reasons beta versions of Windows XP had a completely different theme was to prevent application developers from trying to implement the XP theme in some weird, unofficial framework and create broken and inconsistent looking applications by rendering the XP style themselves. As XP wasn't finished yet shipping every real iteration would've probably only caused more of these inconsistencies, so I think shipping the real theme close to release date was the right move.

If applications used the theme APIs, they'd run fine on both beta and production versions of Windows. If applications tried to render bitmaps over title bars and such, they'd look weirdly out of place, because the real theme was extremely different.

Unless you preferred the beta Windows XP style, of course, which some people did. I think there were a few hacks you could do to get the beta theme working on release versions of Windows.


> prevent application developers from trying to implement the XP theme in some weird, unofficial framework and create broken and inconsistent looking applications by rendering the XP style themselves

That certainly did not work, as billions of applications, including big ones, were using third party “XP-like” and “XP with some twist” skins both in Windows 9X and XP builds.

Microsoft very likely wanted to have some control over commercial skinning market (and make people making those broken things care about compatibility) — alternative themes were supposed to be available to users after being signed by Microsoft. However, you can count the number of those themes on one hand, because others' response was “providing a patched version of uxtheme.dll for each update”.

The other problem was that fashionable XP interface features like colourful side panels in Explorer and Control Panel were windowless controls made with internal layout engine, and neither was available to the public. So the only option was to re-implement those things more or less faithfully, which was done by many developers of commercial UI libraries.


That only happened after the official release, and of course Microsoft couldn't stop anyone from taking a screenshot of the title bar and buttons.

I'm not sure if they wanted to sell themes, really, all theming I've ever seen them sell was based on Windows Media Player and I don't think they did a lot of business in that. Most of the themes were free and the ones that cost money often came back for free a while down the line.

The explorer panels didn't seem to catch on outside of Windows Explorer. Most apps that implemented the bar also didn't seem to make good use of it, in my opinion. Microsoft Office had it, but it always made the screen feel a bit crowded in the way they stacked it with controls and panels, while being completely empty at other times. I think the panel made sense for explorer, but not much elsewhere.

I do wonder if there was an API for the side bar if you used the CLSID explorer interface.

I think Microsoft should've exposed the control, but at least they released a lot more native controls when Vista came around.


I meant that skinning has already been cool before XP, with various degrees of attention to detail and various amounts of system hacks. WindowBlinds for the whole system, application-level reskins. Even Java applets were once considered cool simply because they used their own UI toolkit! Moreover, Microsoft had essentially sold wallpapers and cursors as Plus packs.

However, after the release of XP developers did not stick to using correct native components that would automatically look like Windows 98 on Windows 98, and like Windows XP on Windows XP. They continued to reinvent everything via third-party skinning libraries, but now with kind-of-hip kind-of-XP styles. Random example:

http://web.archive.org/web/20041213230620/http://www.helium2...

Native menus don't work like that. The gradient between “Standard theme” and “Silver theme” background colors is someone's invention. Scrollbars should reach the top of the table views, and their native headers look different. Extra shadows here and there. etc., etc. Everything is improperly remade.

I suppose it was an important topic if they specifically introduced visual style signing at the time when system files and drivers were not even required to be signed. Maybe the perspective of new antitrust trials botched another EEE campaign, maybe the peasants just refused to bow to the king that time.

As for undocumented framework, look up "Windows DirectUser Engine" and "DirectUIHWND". Here's someone fighting with Raymond Chen in comments over IE pretending that having a copy of undocumented system library does not consist of using undocumented Windows APIs:

http://web.archive.org/web/20080329044328/http://blogs.msdn....

The name “DirectUI” is spilled in other comments:

http://bytepointer.com/resources/old_new_thing/20050211_035_...

Side note: as bytepointer archive is badly indexed for this or that reason, I've wasted more than an hour trying to find the post I vaguely remembered seeing. A single mention of "duser.dll" on HackerNews has finally helped me:

https://news.ycombinator.com/item?id=7811284

P.S. Nice contemporary controls re-implementing those Explorer panels from scratch (and copying the name):

https://www.codeproject.com/articles/3216/directui-window-as...


For the sake of completeness: find the differences between bytepointer.com link above, and this earlier copy:

http://web.archive.org/web/20061112210203/http://blogs.msdn....


Windows isn't any special compared to Linux or macOS though is it? IME 90's MacOS was most known for funny looking apps, the custom UI thing probably started with Kai's Power Tools:

https://www.google.com/search?q=Kai%27s+powertools+screensho...


That's not true; apps with non-native UI were usually scorned by Mac users. KPT and other Metatools or (whatever they called themselves that week) stuff was an exception.


I remember Borland shipping a toolkit with horrible built-in skins well before Windows XP.

I even vaguely recall MS jumping on this bandwagon with some MFC styles.


There was a fad for putting icons on dialog buttons. That was the most obvious Borland stylistic trait. Big green check mark on "OK" etc.

That, and Delphi applications not having a minimize to tray animation due to the application window technically being invisible.


Hang on hang on...

> There was a fad for putting icons on dialog buttons. That was the most obvious Borland stylistic trait. Big green check mark on "OK" etc.

This I remember well. It was a hallmark.

> That, and Delphi applications not having a minimize to tray animation due to the application window technically being invisible.

Say what now?!


The VCL has a window managed by TApplication and it's the window which shows up in the task bar, but it's not the application's main window, which is generally a TForm descendant. When you minimize the main window (certainly on Windows 7 and before - I'm not sure about what happens these days) it would just vanish, while a tiny little animation not related to the main window would briefly show disappearing into the task bar button.

The application's window message queue was used for things like coordinating background thread actions with the UI thread and other general purpose stuff - I don't remember the details and it's been a long time since I read the VCL source.


Wow. I had no idea. Thanks!




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: