http://windows.microsoft.com/en-US/windows-8/consumer-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.
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).
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.
The “no MIDI in WinRT” scares me a little. Wonder if that’s going to change.
I think that WinRT actually looks like a pretty good API, but the thought of supporting yet another completely new platform… Aghh…!!
Very likely. There were no midi APIs in iOS to start with, either.
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.
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:
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).
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:
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.
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.
[quote]
There is no need for Javascript, all the WinRT code can be done in C++/CX.[/quote]
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.
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/windows/apps/br229567(v=VS.85).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/BUILD2011/PLAT-766T
Code Sample: http://code.msdn.microsoft.com/windowsapps/
[quote=“sonic59”]There are three ways to make a C++/CX WinRT app:
XAML UI
Javascript UI
DirectX UI
[/quote]
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. 
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
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
DirectWrite hello world sample
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.
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.
Did you see that ?
2 tablets models
[list]
[] Intel one running Windows Pro[/]
[] ARM one running Windows RT[/][/list]
RT version means that we need a new juce supported plateform.
Release date seems planned for october,
Any plans on this ?
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.
[quote=“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.[/quote]
FWIW, a Juce 2.x built app runs on the x86 version being shown for demos right now… 
Aside from the possibility of another Zune, I don’t think that a little lag on Win RT support would be a bad thing at all. I missed Sonic’s response above back in March. At that point, he would have been mistaken. The Marble sample he posted would only run on Windows 8/x86, not Win RT. Officially, that really just changed over the last few weeks, with a public announcement today.
It’s still not clear what ‘very little programming changes’ means… It will probably be another few months before the form a JUCE port is required to take is really settled. Officially, it still looks a lot more like the Android port at the moment, but it was only back in March that Microsoft was swearing that the DirectX choices were fixed and that game developers would just easily adapt… I wouldn’t hold my breath over not needing the idiotic Microsoft specific C++ extensions (Zune meets CLI perhaps?), but there has been some noise about some additional services besides DirectX being available from the pseudo C++ side on the non public forums.
I disagree. The marble sample was originally posted during Microsoft Build conference on September 14, 2011. [1] It was well known that the sample was a “Metro” app not a “Desktop” app. [1] Also during the Build conference it was confirmed by Microsoft that only “Metro” apps would be run on Windows on ARM machines. [2] [3]. Thus it was public knowledge in September 2011 that the Marble sample would run on ALL versions of the new Windows regardless of architecture (x86/x64/arm).
[1] Shows | Microsoft Learn
[2] Developing For Metro – WinRT: The Metro API - Microsoft BUILD: Windows 8, A Pre-Beta Preview
[3] http://www.microsoft.com/investor/downloads/events/09142011_FAM_ExecQA.docx
Today’s announcement had to do with Windows Phone 8 not Windows RT.
Windows 8 is already at Release Candidate status, I highly doubt the API will be changing much if at all at this point.
You are not required to use C++/CX. You can use the Windows Runtime C++ Template Library instead. [4]
[4] http://msdn.microsoft.com/en-us/library/hh438466(v=vs.110).aspx
[quote=“sonic59”]At that point, he would have been mistaken. The Marble sample he posted would only run on Windows 8/x86, not Win RT. Officially, that really just changed over the last few weeks, with a public announcement today.
I disagree. The marble sample was originally posted during Microsoft Build conference on September 14, 2011. [1] It was well known that the sample was a “Metro” app not a “Desktop” app.
[/quote]
Uh, you do realize that Metro is the new look of Windows 8, period, right? Metro is the desktop, and not just on tablets (see the link for the sample app in question, it points you to the Windows 8 Preview).
Metro pretty much looks like Metro on all platforms (Windows 8 x86, Windows 8 WinRT, Windows Phone 8), but WinRT and x86 do not really completely overlap. Just how much and where has undergone a ton of changes since the beginning of the year. The reason that the phone announcement matters, is it is the best indicator for the WinRT winds of change. It is a WinRT platform.
One reason that our perspectives may be so out of sync is we’re already developing for the platforms, with Microsoft. From that point of view, things still seem pretty fluid and subject to pretty rapid change. For folks not on the bleeding edge, the messaging from Microsoft probably makes things seem a lot more seamless and road mapped. I’m pretty sure that Windows 8 (x86) will launch on time. It’s basically Metro UI on top of existing Windows. Win RT (Windows on ARM) seems a lot more iffy. A few vendors have announced that they will have tablets, etc. (ASUS, Microsoft, etc.), but everyone is being coy about launch dates for a reason- and it’s obviously not hardware, companies like ASUS already make ARM tablets in volume.
One thing about the Surface(s) announcement that concerned me was how much crappier the WinRT unit’s display was, not just compared to the Win Pro (x86) version, but current iPad/Android offerings. I heard some rumors about this from one of the HW OEMs, but didn’t believe it until the tablets were actually announced.
Metro - A design language common to Windows 8, Windows RT, Windows Phone 8, Xbox [1] [2]
[1] http://www.microsoft.com/design/toolbox/tutorials/windows-phone-7/metro/
[2] Metro (design language) - Wikipedia
Metro style app - An app that can run on Windows 8, Windows RT, can be sold through the Windows App Store, programmed using the WinRT API and a reduced set of Win32/COM APIs. [3]
Desktop app - An app that can run on Windows 8, cannot be sold through the Windows App Store, programmed using any Win32/COM API[4]
[3] http://msdn.microsoft.com/en-us/windows/apps
[4] Build desktop apps for Windows | Microsoft Learn
x86/x64 Architectures - Can run Windows 8. Windows 8 can run Metro style apps and Desktop apps. [5]
ARM Architecture - Can run Windows RT and Windows Phone 8. Windows RT can run Metro style apps. [5]
When I said:
I was referring to “Metro style app”. I just left out the word style.
The marble sample is a “Metro style app”. [6]
I’ve been running windows8 on my desktop for some time now, and i must say the METRO UI is useless on a classic keyboard+mouse setup, it’s a pain to navigate and i don’t know if i want to get used to that (i stay on the classic side of the windows UI, though the lack of Start button and some other changes make it even harder to work with).
I have a dual monitor display and in Win8 there are hot corners or hot edges, with 1680x1050 resolution on each one, hitting the desired areas to get those slide-menus to open is a pain in the ass to say the least. I don’t know how that classic side of windows will evolve but the road they’ve chosen so far scares me a little. There has been some info from MS that they will start making their own hardware like Apple. Don’t know what this means for normal PC users like me. It’s been already said that the ARM hardware with Win8 will be locked down (http://www.extremetech.com/computing/114173-windows-8-secure-boot-calm-down-microsoft-is-simply-copying-apple) with x86 open (or partially open).
The good news is that the free version of Visual Studio will be available and will support normal windows API not like it was said before that it will only do WinRT.
