Windows8 any takers ?

[atom]

http://windows.microsoft.com/en-US/wind ... er-preview

i just downloaded it and am testing it with my JooJoo tablet, there is a lot of touch support and a ARM option for it. Just thought people might start thinking about this. It's very tablet friendly, but a little bit slow.

[atom]

Anyone knows if the new Windows will have any new Audio/MIDI APIs? Also i was wondering if any VS already supports win8. It looks quite nice there is an app store and a brand new interface (though the old desktop is there but no start menu).

[sonic59]

Good to see someone other than me start talking about Windows 8!

There are two APIs in Windows 8:
Win32
WinRT

There are 3 platforms for Windows 8:
x86, x64
ARM

Software built with both APIs run on all x86 and x64 machines. Only software built with WinRT will run on ARM machines.
The Windows App Store only accepts applications written in WinRT.

There are no new Audio or MIDI APIs that I am aware of form Win32.
Only VS 2011 can built WinRT apps.
There are no MIDI APIs in WinRT. WASAPI (Window's modern Audio API) is available in WinRT.

It should be possible to run Juce applications using WinRT once Juce is ported to WinRT.

[atom]

The "no MIDI in WinRT" scares me a little. Wonder if that's going to change.

[jules]

I think that WinRT actually looks like a pretty good API, but the thought of supporting yet another completely new platform.. Aghh...!!

The "no MIDI in WinRT" scares me a little. Wonder if that's going to change.

Very likely. There were no midi APIs in iOS to start with, either.

[P4tr3ck]

I am also looking into Windows 8 and Visual Studio 11. Because the Windows App Store allows WinRT / Metro Style apps only it would be great if Juce would support the plattform.

C++ is a first class citizen for developing with the WinRT API which should hopefully ease the trouble of supporting the plattform. I imagine that many Juce modules will compile without problems when targeting WinRT. There are some Win API calls that are not allowed but not too many iirc.

[jfitzpat]

C++ is a first class citizen for developing with the WinRT API which should hopefully ease the trouble of supporting the plattform. I imagine that many Juce modules will compile without problems when targeting WinRT. There are some Win API calls that are not allowed but not too many iirc.

Actually, when you are on Windows 8 on an x86/x64 machine you have access to all the Win API calls, because that is what you are actually calling from your DLL. But on, for example, ARM platforms, no Win32 calls are available at all:

http://blogs.msdn.com/b/b8/archive/2012 ... cture.aspx

Also, as it stands, if you call Win32 functions you'll be rejected from the Windows App store. I'm also not so sure about 'first class citizen' status. Microsoft left C++/CLI back in the dust with .NET 3.0. From the few minutes I've played with this latest contraption, it is more of a fake C++ on top of a scripting language. Things like stack variables are translated, by "compiler magic" into heap allocations.

This is not nec. a bad thing. But it does make a Juce implementation closer to the Android implementation than the Win32 (Javascript on the Metro side, psuedo native code from C++ in a bundled library).

[sonic59]

But on, for example, ARM platforms, no Win32 calls are available at all

This is incorrect.
Microsoft will allow you to use a very select amount of Win32 APIs in a metro app. If you use these Win32 api's in your metro app, you will not be rejected from the Windows App Store.

The list of these API's can be found here:
http://msdn.microsoft.com/en-us/library ... 05757.aspx

This list includes more moderns apis like WASAPI and Direct2D. Unfortunately it does not include stoneaged MME MIDI API.

There is no need for Javascript, all the WinRT code can be done in C++/CX.

[jfitzpat]

This is incorrect.

Well, I was paraphrasing the Microsoft guy (see link), Win32 is effectively gone and you need to use WinRT services instead to run on ARM. If you think COM services (which is how WinRT itself is accessed) and a few otherwise uncovered, mostly COM based services are enough for 'most Juce modules to compile without change' - the context of my comment, well, I just don't see it. Virtually all the Windows native files use services that aren't there.

There is no need for Javascript, all the WinRT code can be done in C++/CX.

That's interesting. Can you explain how it is supposed to work? With the tools I got, I can only make a C++ WinRT dll. I did not know I could make an app. It certainly seemed like you needed XAMP or HTML/Javascript to have a UI (much the way that the NDK only makes libs on Android). But perhaps I was mislead by all the samples so far. Bing Maps, etc. Are all ' hybrid' apps. I thought it was because of the missing binding stuff that is inherent in .net languages. I did see a bunch of weird MS language extensions, but I thought they were just there to make using the COM interfaces easier.

If you can do a metro app with C++ alone, that might make a juce port a little easier. I'd be interested in hearing more.

[sonic59]

I agree, 95% of Win32 is gone but at least some APIs remain.

There are three ways to make a C++/CX WinRT app:
XAML UI
Javascript UI
DirectX UI

http://msdn.microsoft.com/en-us/library ... 85%29.aspx

When Juce gets ported WinRT, it will likely be done using the third method, DirectX UI. Windowing and Input will need to be done using WinRT. Graphics rendering would be done via Direct2D. Text rendering will be done using the existing DirectWrite code in Juce. Audio will be done using the existing WASAPI code in Juce.

Juce apps would continue to look the same across all platforms and look nothing like native metro apps (just like how things are on IOS).

For more details on DirectX UI metro apps:
Video: http://channel9.msdn.com/Events/BUILD/B ... /PLAT-766T
Code Sample: http://code.msdn.microsoft.com/windowsapps/

[jfitzpat]

There are three ways to make a C++/CX WinRT app:
XAML UI
Javascript UI
DirectX UI

You lost me at the third one. You can use DirectX for complex content rendering, but the linked keynote talk describes a hybrid application. All the linked samples also appear to be hybrid applications. I *assumed* Juce would use DirectX, that's why I mentioned Javascript. As it stands, C++ code running on WinRT can use DirectX or XAML, but not both simultaneously. That might change with the final release (some higher profile game folks are howling for it), but, at the moment, it seems that Javascript is the logical choice for a content/context provider for a predominantly C++/WinRT app. I have no idea why you think that would require Juce apps to have a Metro look. It actually should require a lot less back and forth than the Android port, which currently does soft rendering to pass on as a glyph by default. I also still don't see how you intend to avoid the glue altogether. Though, frankly, I don't really care all that much.

All my existing apps and kernel level drivers run on Windows 8 now. I'll take WinRT seriously when it's actually released and Windows ARM devices are 5% of the market.

[P4tr3ck]

Yesterday's release brought coexistence of dx and xaml ui:
http://blogs.msdn.com/b/windowsappdev/archive/2012/03/01/what-s-changed-since-build-part-1.aspx

[sonic59]

I don't know what samples you are looking at, but the samples I am looking at don't have any Javascript or XAML in them, just C++/CX.

Metro style 3-D maze game sample
http://code.msdn.microsoft.com/windowsa ... e-e4806345

DirectWrite hello world sample
http://code.msdn.microsoft.com/windowsa ... d-760793d2

I have no idea why you think that would require Juce apps to have a Metro look

I don't think that.

I previously said:
Juce apps would continue to look the same across all platforms and look nothing like native metro apps (just like how things are on IOS).

In hindsight, "native metro apps" was a poor choice of words. I meant that by default, Juce apps would not have the metro look or metro widgets just like Juce apps on IOS don't have an IOS look or IOS widgets. However, with a bit of effort I'm sure developers will be able to figure out how to get metro looking JUCE apps just as they have done with IOS looking JUCE apps.

I also still don't see how you intend to avoid the glue altogether.

There is no way to avoid it altogether, Juce needs to be ported to the WinRT platform. There just is no need to involve any Javascript or XAML.

[lilin]

Did you see that ?

http://www.engadget.com/tag/surface/

2 tablets models

• Intel one running Windows Pro
• ARM one running Windows RT

RT version means that we need a new juce supported plateform.

Release date seems planned for october,
Any plans on this ?

[jules]

Yes, sounds interesting.. (Or maybe another Zune-type disaster!)

I'm way too overstretched at the moment to consider doing a Win8 port in the near future though.