Live data from Hacker News

Microsoft introduces Universal Windows apps

wmpoweruser.com

151–160 of 187 posts

Re: Microsoft introduces Universal Windows apps

#151
post #105

Earlier quoted context omitted.

What about the internals? Is it still kind of a mess under the hood? I heard they rebuilt the TCP/IP stack so it's not user land 32 bit driver anymore. Any ideas if/when they'll modernize NTFS? Right now it's a race to the bottom to who has the worse FS, HFS+ or NTFS. WinFS or ZFS on OS X would be a godsend. What about the registry? Any idea if they'll make that easier to manage for regular people? Am I still fucked…

No it's rock solid underneath. The TCP stack hasn't been a 32-bit driver since XP. NTFS has been modernised already: http://en.wikipedia.org/wiki/ReFS The registry is fine - it's people pissing around in it that break it. Win32 - haven't touched it for years. Driver model: not my problem. Mavericks is a crime compared to windows 8.1. I use both, regularly. It's virtually impossible to use efficiently with a keyboard…

All these points are fine but theres no reason to flat out lie about the quality of Mavericks....

1) Keyboard shortcuts are fine, if u use a OSX all day every day you will think Windows shortcuts are bad. That and you can edit pretty much every single shortcut in OSX if you are really that offended by them.

2) If your apps are crashing every 2mins (or even more than once a week...) your computer is f'd.

Re: Microsoft introduces Universal Windows apps

#152

Earlier quoted context omitted.

Exactly, except Microsoft has taken it to the logical conclusion we all want supporting all platforms, and sadly Apple hasn't. I have code that runs on both iPhone/iPad and shares most of it with the Mac version yet I have to build the Mac as a separate app and submit to a different store. That sucks.

I bet that apple is working on this, and Microsoft just got there first. Not to take anything away from Microsoft, this is awesome!

Totally.. see the appearance of TextKit on iOS using tons of NS* classes instead of UI* classes, and UITextAlignment being replaced with the OSX NSTextAlignment, etc.

I doubt its a very high priority though given how small the OSX Desktop market is in comparison.. it'll just be a very slow merging ;)

Re: Microsoft introduces Universal Windows apps

#153
post #51

Earlier quoted context omitted.

Mono! Lots of ASP.Net projects (like Nancyfx or SignalR) are actually built on Mono. I think there's some hope that web dev on Windows isn't dead.

I tried Keepass2 with mono on Linux and it's pretty slow and unnatural UX experience. Much like running Wine. On OSX Keepass2 mono just froze constantly and looked weird. I've had similar experience with other cross-platform apps. Total cross-platform is a pipe dream. Just like Java or more recently HTML5/JS cross-platform mobile apps, they are almost always a half-baked solution compared to proper native OS apps. Th…

Mono makes no pretext of offering cross-platform GUI live, and so any app that attempts to use the same GUI on multiple platforms using winforms on Linux or gtk on win32 is going to be ugly. They're up front about this.

Re: Microsoft introduces Universal Windows apps

#154
post #51

Earlier quoted context omitted.

Mono! Lots of ASP.Net projects (like Nancyfx or SignalR) are actually built on Mono. I think there's some hope that web dev on Windows isn't dead.

I tried Keepass2 with mono on Linux and it's pretty slow and unnatural UX experience. Much like running Wine. On OSX Keepass2 mono just froze constantly and looked weird. I've had similar experience with other cross-platform apps. Total cross-platform is a pipe dream. Just like Java or more recently HTML5/JS cross-platform mobile apps, they are almost always a half-baked solution compared to proper native OS apps. Th…

Naturally mono probably has some quirks, which you need to keep in mind during development. However, you can make successful apps using it. The Unity3D engine uses mono on linux, and the games using it run fine (even on my laptop).

Re: Microsoft introduces Universal Windows apps

#155
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…

Have to disagree with you there. Windows is older than COM. It's actually older than C++. The classic core Windows libraries and interfaces like GDI are plain old C. Not even a hint of C++.

COM is language agnostic. You can consume COM servers in Delphi that have been written in VB. Again, no C++, not necessarily. The only "true" C++ API I'm aware of is GDI+. Everything else to my knowledge was and is either straight C or COM.

Re: Microsoft introduces Universal Windows apps

#156

Earlier quoted context omitted.

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, mess…

If by "boilerplate" you mean creating/registering a window class before creating a window, you don't need to do that if your application's UI largely looks like dialogboxes - DialogBoxParam will create a message loop automatically and all you need to give it is the layout template and the message calback WndProc. (I've been working with Win32 for around a decade now, it's got its warts but really isn't that bad once…

Sure I am not arguing about the whole of Win32, just the fact that it would have been easy to modify the API a bit so that main() was the entry point for a normal windows app.

Re: Microsoft introduces Universal Windows apps

#157
post #123
post #106

Earlier quoted context omitted.

> he amazing thing is that you can potentially write all your code in C and have backend/frontend logic for the web, Windows, Windows Phone, OSX, FreeBSD, OpenBSD, Tru64, VAX, Arduino, Linux Kernel, Windows Kernel, Mach, Hurd, and practically every processor or operating system ever built, and even iOS/Android (via Xamarin). Wow. Have you ever done C development like this, ever in your life? I did. Between 1994 and 2…

The only portable GUI code that I've ever seen work somewhat reliably is HTML/CSS. Everything else either implements a 3rd GUI, Swing, et al, or looks weird on a few of the platforms, GTK. Oddly enough the best cross-platform lib I've seen, Qt, is written in C++. C certainly isn't the be all and end all, however, it's far more portable, reusable, and linkable than C#.

From a platform perspective, Qt is good for all the desktop environments, but for mobile, .NET/Xamarin is the way to go.

From a language perspective, why in the world would you want GUI code in C or C++? Both languages make it very easy to shoot your foot off and have no idea what happened. However, C can be very elegant if used for the right reasons. C# is safer, but also not perfect. That's where F# comes in. :)

Re: Microsoft introduces Universal Windows apps

#158
post #145

Earlier quoted context omitted.

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, mess…

At least they provide the mainCRTStartup thing [1] so you can use main() in GUI executables. Regarding boilerplate, Win32 was designed as a very low level API, with MFC and other high level libraries to make things easier. [1] http://stackoverflow.com/questions/11785157/replacing-winmai...

I didn't know about the mainCRTStartup thing, thanks. But it should have been the default - to me WinMain() is just a failure to understand what is best exposed and what is best encapsulated. My boilerplate reduction proposal is to provide a few helper functions to optionally avoid exposure to some of the pipework - just to make life a bit easier when starting out. MFC on the other hand is a massive new layer of compromises and other crud slapped over the top of the Win32 API - somehow managing to make it even more cryptic (YMMV). Also MFC postdated the Win32 API by a few years, so presumably wasn't considered as the first choice solution at the start. The first Petzold book was a C thing, MFC and C++ came later.

Re: Microsoft introduces Universal Windows apps

#159
post #140
post #137

Earlier quoted context omitted.

>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 d…

What in the world are you talking about? Apps in Xamarin can be as much as 10mb for a full app. Its linker is smart and knows not to bring in stuff it doesn't need. If you don't, it's around 40mb.

Re: Microsoft introduces Universal Windows apps

#160
post #157
post #123

Earlier quoted context omitted.

The only portable GUI code that I've ever seen work somewhat reliably is HTML/CSS. Everything else either implements a 3rd GUI, Swing, et al, or looks weird on a few of the platforms, GTK. Oddly enough the best cross-platform lib I've seen, Qt, is written in C++. C certainly isn't the be all and end all, however, it's far more portable, reusable, and linkable than C#.

From a platform perspective, Qt is good for all the desktop environments, but for mobile, .NET/Xamarin is the way to go. From a language perspective, why in the world would you want GUI code in C or C++? Both languages make it very easy to shoot your foot off and have no idea what happened. However, C can be very elegant if used for the right reasons. C# is safer, but also not perfect. That's where F# comes in. :)

I actually had a super hard time with F# and XAML, this was back in F# 1.0/1.1 days.

While not strictly C, ObjC/UIKit is a helluva language for doing GUIs.

I actually don't like GUIs in C++/Java, or C# because it's far too restrictive and you spend all your time making the class hierarchy happy and typing boiler plate rather than getting stuff done.

ObjC is a beautiful mix of scriptyness and performance / low memory utilization. If ObjC is too slow, C is right there, and if it's too complicated for C add in a little C++. My typical mix is usually about 90-95% ObjC, 5-10% C, and 1% C++.

I love that if you know an object supports a method you can just cast to id and call it. If an object is missing a method, you just add it. If a base class is stupid, you override it.

Java/C# are total pieces of crap in this regard, although C# is far better for having extension methods.

Post reply on HN