Live data from Hacker News

Microsoft introduces Universal Windows apps

wmpoweruser.com

131–140 of 187 posts

Re: Microsoft introduces Universal Windows apps

#131

Earlier quoted context omitted.

I think your underestimating the INSANE amount of vision and foresight that would be required to do this in 2005. 1. The xbox 360 was released in 2005. This was essentially the first Microsoft console to run 'apps,' and those had to be architected specifically for the console. 2. The iPhone was years away in 2005. Phones ran shitty little apps that had to be architected specifically for the phone. 3. The iPad was yea…

The idea of a centralized "app store" was not new. People had been complaining about Windows not having Linux-like package management since the 90s. Similarly, the idea of web apps taking over everything was not new. Microsoft was acutely aware of that, since that was Netscape's big idea (also Java was in theory the same threat - write once, run anywhere, make Windows unimportant). Again, all in the 90s. This is the…

Microsoft had an application store in Windows XP. Remember "Find applications"? They had an online store of sorts that listed programs, but nobody bought anything on it because there didn't appear to be any vendors on it, and CD-ROMs were all the rage back then. App Stores have only really taken off as Internet speeds have sky-rocketed. That was not the case when XP was released; everyone was on dialup or barely slow ISDN if they were lucky.

Re: Microsoft introduces Universal Windows apps

#132
post #30

They must live in quite a bubble if "universal" only includes Microsoft platforms.

Weirdly, PE executables on Windows are Portable Executables that the system model would permit to run under not just Intel but other architectures.

Sadly the other platforms died so the portable executable is really just the stuck executable.

Re: Microsoft introduces Universal Windows apps

#133

Earlier quoted context omitted.

Wow, is that thing really embedded C++? Bjarne always said that embedded C++ deserved to die if it wasn't already dying, mainly because it appears to remove all the useful bits of C++ to make it some static-typed-only inheritance mush put on top of C, as I understand (most likely wrong).

Yup http://en.wikipedia.org/wiki/I/O_Kit . I mean Embedded C++ is not really a language, any C++ compiler can be turned into an "Embedded C++ compiler" by turning some features off. As to the Bjarne quote, a lot of things that are nice in application development can become tricky when you are closer to the metal.

Thanks for the link. The bare metal thing is probably why C guys typically see C++ as bloated and why I look at C and think "how do you write anything?!?!!"; I live happily in C++ land you see.

Re: Microsoft introduces Universal Windows apps

#134
post #84

Earlier quoted context omitted.

int main(){ puts("Hello World"); } This doesn't work in Windows. The standard entry point to Windows is "int CALLBACK WinMain( _In_ HINSTANCE hInstance, _In_ HINSTANCE hPrevInstance, _In_ LPSTR lpCmdLine, _In_ int nCmdShow );" C never really "ran" on Windows. C is built on top of abstractions to even run on Windows. A SegFault in standard C is supposed to be passed to a signal handler (in Linux/ OSX). A SegFault in W…

Microsoft seems to think that it'll work: http://msdn.microsoft.com/en-us/library/bb384838(v=vs.110).a...

MS also has more people using a 14 year old OS than their latest and greatest.

Re: Microsoft introduces Universal Windows apps

#135
post #66

Earlier quoted context omitted.

You can rely on C# being on all platforms by default? Linux and OS X? Really? Last time I used Windows (several years ago), there were always apps that needed to download and install the latest version of the .NET runtime... - is that still a thing?

int main(){ puts("Hello World"); } This doesn't work in Windows. The standard entry point to Windows is "int CALLBACK WinMain( _In_ HINSTANCE hInstance, _In_ HINSTANCE hPrevInstance, _In_ LPSTR lpCmdLine, _In_ int nCmdShow );" C never really "ran" on Windows. C is built on top of abstractions to even run on Windows. A SegFault in standard C is supposed to be passed to a signal handler (in Linux/ OSX). A SegFault in W…

I always thought that the whole WinMain() thing was an ugly mistake. The right way to do this would be to organise the libraries and startup code so that the simplest Windows GUI program was not 50 or 100 lines of boilerplate, but was instead something like;

  #include 
  void main()
  {
    WinGuiInit();
    WinGuiMessageLoopRun();
  }
Or similar. Extra functions and parameters as required to setup custom icons, window classes, message handlers, whatever.

Re: Microsoft introduces Universal Windows apps

#136
post #27

I'm still trying to figure out how/why this makes sense as a goal. Building an application that runs across multiple platforms in congruent spaces makes sense: iOS and Android and Windows Phone. When you move to running the same application across Laptop vs. Phone style platforms, even on modern hardware, you're looking at capabilities and resources that are radically different. I can see wanting to share certain com…

The real key here is sharing business logic. Microsoft apps are written using the MVVM (Model View, View-Model) framework. The idea here is that you would share almost all of your model code, and really only rewrite the view layer (XAML) per platform. You're also allowed to share the exact same views across platforms, but it's unlikely that will be a good experience for users, given the differences: screen sizes, inp…

The other key is that for people who have invested in other platforms, they know that they can get more bang for their buck on MS by buying one app everywhere. That would be a big deal for me if I ever come home to Windows.

Re: Microsoft introduces Universal Windows apps

#137
post #125

Earlier quoted context omitted.

Have you ever actually used C in a real project? I can't seem to get away without using any compiler specific constructions, much less operating system specific call routines. There isn't even a Boost for C. Honestly, I'd be surprised if you actually knew C with a statement like that.

Have you ever tried to get C# code deployed on Linux, OSX, and Windows? You end up at exactly the same point you did with C, except now you have 100-500 MB of garbage to haul around with your application. Cross platform dev and deployment is hard, Java and C# just push the work somewhere else while adding garbage that gets in the way. If you want to make GUIs for iOS,Android,Windows,OSX, and Linux use HTML/CSS/JS. If…

>Java and C# just push the work somewhere

You mean someone else, which is the entire point of why you would use any platform/library/framework.

Re: Microsoft introduces Universal Windows apps

#138
post #70

One thing I don't see mentioned, do universal apps support C++11? I can understand why it's not as easy to support native code across platforms (i.e. need to do some kind of fat binary thing), but think it's a little sad to see all the work done to support modern C++ app development kind of abandoned. Really annoying if you have to choose between an app being universal or written in modern C++.

AFAIK they do. WinRT apps can be written in many languages including C++. And this is pure native C++ and not "managed" C++.

Yes I'm aware of that, but can universal apps be written in native code? I don't see any mention of it in their announcement.

Re: Microsoft introduces Universal Windows apps

#139
post #107
post #70

One thing I don't see mentioned, do universal apps support C++11? I can understand why it's not as easy to support native code across platforms (i.e. need to do some kind of fat binary thing), but think it's a little sad to see all the work done to support modern C++ app development kind of abandoned. Really annoying if you have to choose between an app being universal or written in modern C++.

> (i.e. need to do some kind of fat binary thing) Fat binaries aren't needed to support pointer arithmetic or any other C++11 features in a cross-platform binary. LLVM bitcode supports pointer arithmetic. I also believe .NET bytecode supports pointer arithmetic. I'm not sure what other features you thought would require some kind of fat binary.

WinRT lets you write native Win 8 apps in C++, however it doesn't use LLVM or .NET bytecode. If universal binaries are supposed to be supported across different architectures (like x86, ARM, etc.) I don't know of any other way to support it than fat binaries.

Re: Microsoft introduces Universal Windows apps

#140
post #137
post #125

Earlier quoted context omitted.

Have you ever tried to get C# code deployed on Linux, OSX, and Windows? You end up at exactly the same point you did with C, except now you have 100-500 MB of garbage to haul around with your application. Cross platform dev and deployment is hard, Java and C# just push the work somewhere else while adding garbage that gets in the way. If you want to make GUIs for iOS,Android,Windows,OSX, and Linux use HTML/CSS/JS. If…

>Java and C# just push the work somewhere You mean someone else, which is the entire point of why you would use any platform/library/framework.

No I mean somewhere else, because for the most part the cross platform stuff doesn't work.

Oh? You have a cross platform path separator builtin? Wow that must be totally worth 200 MB of garbage.

I'm sure the client will be fine with fucking around with the CLR / JVM all day instead of just downloading a 200 KB executable. It's just what they need, now not only do they need to update your application but they have a dependency nightmare too.

Post reply on HN