Linked by Thom Holwerda on Thu 26th Jan 2012 15:13 UTC
Mac OS X "It's no longer possible to write a single app that takes advantage of the full range of Mac OS X features. Some APIs only work inside the Mac App Store. Others only work outside it. Presumably, this gap will widen as more new features are App Store-exclusive, while sandboxing places greater restrictions on what App Store apps are allowed to do." Anybody surprised by this, here's the clue stick. Please proceed to hit yourself with it.
Thread beginning with comment 504906
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE[7]: No MacOS X for me.
by kaiwai on Fri 27th Jan 2012 14:26 UTC in reply to "RE[6]: No MacOS X for me."
kaiwai
Member since:
2005-07-06

They kept the parts around that made sense - or are you arguing Mac OS X wasn't a clean break because it still kept things like QuickTime, Desk Accessories, and more, from the MacOS days aound?


You've failed to address the question as to why WinRT depends on GDI when there is Direct2D/DirectWrite available. Regarding Mac OS X, unlike Microsoft, they killed things off and didn't pussy foot around when doing it where as Microsoft seems to be like the parent who is scared to make a decision believing that if they make the wrong one their children won't love them any more.

Edited 2012-01-27 14:28 UTC

Reply Parent Score: 2

RE[8]: No MacOS X for me.
by moondevil on Fri 27th Jan 2012 14:30 in reply to "RE[7]: No MacOS X for me."
moondevil Member since:
2005-07-08

You've failed to address the question as to why WinRT depends on GDI when there is Direct2D/DirectWrite available.


Where does it depend on GDI?

Have you coded a Windows 8 Metro application and checked the dll dependencies to assert such statement?

Reply Parent Score: 2

RE[9]: No MacOS X for me.
by kaiwai on Sat 28th Jan 2012 13:28 in reply to "RE[8]: No MacOS X for me."
kaiwai Member since:
2005-07-06

Where does it depend on GDI?

Have you coded a Windows 8 Metro application and checked the dll dependencies to assert such statement?


Sorry for the slow reply, a combination of work (I do night shifts) and I was trying to find the article - maybe I got confused between GDI and USER but it does go back to my question as to where WinRT is for desktop applications. To me it appears that Microsoft has abandoned the desktop in pursuit of 'sticking it to Apple' but doing very little to address the short comings when it comes to frameworks for desktop developers.

Here is one link: http://social.msdn.microsoft.com/Forums/en-US/toolsforwinapps/threa...

I have no official source, but it really seems that WinRT is a new layer on top of Win32 (and DirectX), not like shown in the famous schema. It appears to be a library only, and there is no subsystem.

From other persons investigations:

Some of the new COM functionalities are store in a new dll combase.dll. This dll is some kind of new oel32.dll.

WinRT dlls rely on classical dlls like user32.dll and kernelbase.dll from MinWin.
There are traces of new functions in Win32 like CreateWindowInBand and GetPointerDeviceRects, and new dlls like twinapi.dll which seems to have a classical Win32 interface (C functions like CreateImmersiveWindow).

The window that contains metro app is a classical win32 window. The controls are drawn "manually" like in WPF (Or swing) , probably with a choice between DirectX and an other method. Controls are perhaps managed by DirectUI.dll, which is somehow agcore.dll from silverlight ported to WinRT. But I don't know if DirectUI.dll interface is WinRT, COM or Win32 like.

I am sorry for my mistakes and imprecisions. You can find additional information by googling functions and dlls posted in this message. You should find links to this thread and few others forums.
Anyway, using depends, process explorer and a debugger should be the more effective way to have true information about how WinRT is made.


Now don't get me wrong, if Microsoft is pushing some of those libraries out of win32 into some other category so that both Win32 and WinRT relies on them then I can understand. For example if Microsoft has pushed user32.dll into part of the 'Windows native' layer then sure I can understand but so far what the poster is pointing out is that WinRT is still dependent on some pretty low level parts of Win32.

Edit: Here is another link that might be interesting: http://blogs.msdn.com/b/lixiong/archive/2011/12/05/retrospect-diffe...

So what is it? a subsystem in its own right? sits in between Win32 and Windows Native? it seems that even Microsoft's own employees are having difficulties making heads or tales of it.

Edited 2012-01-28 13:43 UTC

Reply Parent Score: 2