PureBasic Forums - English

While our friends in the MAC forum have long been worried about the impending doom of Carbon, when Apple inevitably deprecates and dumps it in favour of Cocoa, we might be facing a similar problem before long.

Windows 8 has brought with it a whole new API in the form of the COM-based Windows Runtime, which will sit alongside our old friend the Win32-API (for now). The new breed of Metro apps, which run on this Windows Runtime, has very limited dependency on the Win32-API.

While we may still write native Windows apps that should run without any problems for the good foreseeable future, it is clear that once Windows 8 hits the mainstream, we will join the ranks of legacy.

I would call it a different API not the new one.

We all - including Microsoft - know where the power of Windows is: Millions of great applications available for everyone and every need.
For a long time there will be no serious Metro app doing real photo processing, video editing, excel etc. because complex stuff cannot be done effectively in that touch-simplified manner.

Metro is for the consumer who wants to check his Facebook profile, watch a video, see the weather forecast, view some vacation photos etc. ...But it's not for anyone who wants to get something done fast.

http://blogs.microsoft.co.il/blogs/sash ... ows-8.aspx

Next, a C++ Metro application will still load Win32 DLLs such as kernel32 and ntdll. Moreover, the WinRT APIs call into the Win32 DLLs – so they are not a replacement but rather a wrapper, an API flavor, on top of Win32. (Historical note: Windows used to have a feature called “environment subsystems”, which can be roughly described as API flavors. WinRT is not an environment subsystem – it is a library on top of the Win32 environment subsystem

win32 also on ARM:
http://getwired.com/2011/09/20/win32-th ... aggerated/

Win32 API isnt going away.
They would need to rewrite almost the whole OS to replace it. That is not going to happen. They say WinRT is not on top of the Win32 API, but thats just not true. For Metro there is need of a new API, which is WinRT. However all the system stuff is just wrapped Win32 API's.

xorc1zt wrote: http://blogs.microsoft.co.il/blogs/sash ... ows-8.aspx

Sasha Goldshtein wrote:Next, a C++ Metro application will still load Win32 DLLs such as kernel32 and ntdll. Moreover, the WinRT APIs call into the Win32 DLLs – so they are not a replacement but rather a wrapper, an API flavor, on top of Win32. (Historical note: Windows used to have a feature called “environment subsystems”, which can be roughly described as API flavors. WinRT is not an environment subsystem – it is a library on top of the Win32 environment subsystem

From his own statement, "I think I have a pretty decent mental picture of what’s going on", it is clear that Goldshtein is only conjecturing, and from what Microsoft and others are saying, Goldshtein's got it wrong.

MSDN wrote: Metro style apps can use a subset of the Win32 and COM API. This subset of APIs was chosen to support key scenarios for Metro style apps that were not already covered by the Windows Runtime, HTML/CSS, or other supported languages or standards. The Windows App Certification Kit ensures that your app uses only this subset of the Win32 and COM API. (link)

Paul Thurrott wrote:Win32 will, for now, include functionality that is simply not available in WinRT, though hopefully that will change over time. But WinRT, of course, is where the action is: Though some small updates to the Win32 APIs have indeed been introduced in Windows 8, Win32 is largely deprecated and heading towards maintenance mode. All of the big changes and improvements are, and will be, occurring in WinRT. (link)

Martyn Lovell wrote:Windows Runtime:
- is the one Windows API
- is the Modern Windows API
- still uses some classic Win32 APIs
- provides direct access to the Windows core
- will keep apps running on future Windows versions (video link)

If the Windows Runtime is capable of directly accessing the Windows core, it cannot be sitting on top of the Win32 API. And calling it the one and modern Windows API that will keep apps running on future Windows versions, while labeling the Win32 API as classic and limiting its use, clearly show their intended direction. The writing's on the wall.

Similar threads were started all over the forums when .Net was born. Same outcome, same reasons.

What Microsoft is writting officialy is marketing not how it realy works.

Its pretty easy to proof with a debugger like OllyDbg. Win32 API is pretty much right below WinRT. The stuff that dont rely on Win32 API is all the touch and graphics stuff of Metro. They needed a new API for that and decided to make a completly new one instead of integrating it in the Win32 API. However for all system specific stuff Win32 API is in fact called, this can be easiely prooven as i wrote.

It would also dont make much sense to rewrite stuff thats allready there and working just fine. To get it to a COM interface they just wrap it. Same thing that .NET did and still does.

Thorium wrote:What Microsoft is writting officialy is marketing not how it realy works.

Its pretty easy to proof with a debugger like OllyDbg. Win32 API is pretty much right below WinRT. The stuff that dont rely on Win32 API is all the touch and graphics stuff of Metro. They needed a new API for that and decided to make a completly new one instead of integrating it in the Win32 API. However for all system specific stuff Win32 API is in fact called, this can be easiely prooven as i wrote.

It would also dont make much sense to rewrite stuff thats allready there and working just fine. To get it to a COM interface they just wrap it. Same thing that .NET did and still does.

It would really be great if that were true. The various early diagrams actually show WinRT sitting on top of Win32, but then the new ones show them sitting laterally, and that's the position they have taken since. Like you said, it could be a marketing ploy to reel new developers into this quagmire by presenting it with low-level efficiency.

On the other hand, Microsoft is claiming that this new approach will ensure a more stable OS environment, as the new Windows Runtime manages system requests in a safe and cooperative manner; it supposedly prevents hangs and crashes and makes apps more system-compliant. If this is truly the case, they can't allow legacy apps to run amok in such a controlled environment.

As it is, they've already started restricting the use of the Win32 API to just a small approved subset. Let's hope that they don't strip it down to this skeleton subset, and relegate legacy apps to running on some compatibility virtual machine, like they did with the NTVDM for WIn16 and DOS.

I guess we'll just have to wait and see.

Microsoft is claiming that this new approach will ensure a more stable OS environment

Opening-up your OS to the script kiddies is not really going to lead to a more stable environment, that's marketing blurb. To protect the OS and other apps, it might be easier to stop a Metro App however, especially since they want to 'approve' every app. Essentially, MS are copying the Apple model to make money out of other people's hard work, that's really the driving factor.

IdeasVacuum wrote:

Microsoft is claiming that this new approach will ensure a more stable OS environment

Opening-up your OS to the script kiddies is not really going to lead to a more stable environment, that's marketing blurb. To protect the OS and other apps, it might be easier to stop a Metro App however, especially since they want to 'approve' every app. Essentially, MS are copying the Apple model to make money out of other people's hard work, that's really the driving factor.

Regardless of the language used, measures have been built into the Windows Runtime itself to ensure greater stability and compliance. Apps run in private sandboxed environments, and most API calls, especially I/O functions, are strictly asynchronous and returns immediately. These prevent unresponsive hold-ups and hangs, and if a sandboxed app were to crash, the rest of the system would be unaffected. Another requirement is system compliance, which ensures that the OS is boss; for example, when a request to terminate is issued. And then, your code is supposedly portable across WOI and WOA.

Microsoft’s clearly expecting maladroit programmers, but it’s still 30% of a fast-growing developer base. Even desktop apps have to be certified in order to be listed in the Windows Store, and certification means restrictive use of Win32.

The M$ driving factor may be clear, but so is their intended direction with WinRT.

If we need to, we will add a WinRT subsystem, as we added others (linux, OS X). That's doesn't sounds like a problem to me.

Fred wrote:If we need to, we will add a WinRT subsystem, as we added others (linux, OS X). That's doesn't sounds like a problem to me.

PureBasic... great as always!

Fred wrote:If we need to, we will add a WinRT subsystem, as we added others (linux, OS X). That's doesn't sounds like a problem to me.

Hi Fred. That sounds great, although I always knew that PureBasic would continue to evolve with the platforms it supports. Thanks for the reassurance.

I just hope that Microsoft's new API compliance requirements will not result in major revamps of our existing projects.

Fred wrote:If we need to, we will add a WinRT subsystem, as we added others (linux, OS X). That's doesn't sounds like a problem to me.

You need to. Add Metro/WinRT subsystem and Win8/ARM target platform. The time is NOW, at least 1 billion people
want the new Win8 tablet/netbook/PC mainstream combination. Work everywhere. With PureBasic.

A billion people?


Come on now.. And didn't we already have this ARM discussion before? x86 Tablets are coming anyway