Hacker News Reader

Comment by userbinator | Hacker News Reader

Starting early is good, but I think he may have gotten sucked into the UWP hype:

https://news.ycombinator.com/item?id=19873198

https://news.ycombinator.com/item?id=19883351

If the author is reading this, here's some advice for you: I encourage you to start learning pure Win32 and enjoy the benefits of extreme compatibility (you can create a single .exe that works on anything starting from Windows 95, depending on the exact set of features you want) as well as highly efficient native code. It's what made Microsoft and the Windows platform great in the first place, and it will continue to be the "real Windows API" that has lasted through all the other churning trends.

I started with Win16 (and before that was DOS, so not much to speak of in the way of UI), moved to Win32, and basically stayed there while ignoring all the other newer and more short-lived stuff that came and went.

View on HN

Thanks for addressing me with this recommendation. As you may have guessed, I'm the developer of Files UWP. I really have a great deal of respect for those who take the time to learn the guts of the Windows API which simultaneously teaches one how Windows itself works. I won't deny it. There is certainly something pretty great to learning a subsystem written under Gates himself.

Further, there have been many instances where I've grown quite tired of the limitations surrounding UWP. Just this evening, I discovered we simply can't check the maximized/minimized state of the app windows. While this limitation probably dates back to Win 8, this functionality is taken for granted by Win32 devs. Don't get me started on how slow some of the Windows.Storage APIs are compared to that of Win32.

Because of these reasons, I'll kindly admit to you guys that a file explorer application probably SHOULD be written using completely-native Windows APIs. I can't deny the UX improvements brought by Fluent Design to controls have been great, but I'm NOT blinded by my own ignorance. UWP (in it's current state) is not ready for adoption. In fact, I started work on Files last year with no real knowledge of what an API was. (My knowledge of programming concepts has come a long way since then) Come February 2019, I posted the project to Reddit with the intention of abandoning it, but I was blown away by the overwhelmingly-positive community feedback to the point where I continued work on the project. I almost feel obligated to, at the very least, maintain it.

Dude, it's super cool anyway, keep it up!

And since you're so young: don't get too attached to a tech if you consider it a dead end or not ready for primetime.

Personally, I'd go for a Qt app next, if you like desktop apps.

You can use UWP controls in Win32 apps now, and still distribute via the Store. Look up XAML Islands. It’s how the new Windows Terminal works.

I’d recommend pursuing that route if you’re frustrated by UWP app limitations or performance.

Full disclosure: I work at Microsoft on the Windows team.

Ignore the negativity that often gets posted here. For a student app, this is quite impressive.

Developing on the windows API is an unproductive way of creating apps, especially for the beginner developer.

It's much better to invest their time on learning programming rather how to possition a button and where to listen for click messages.

This is especially true today that the ui standars envolve in such fast pace.

Developing on the windows API is an unproductive way of creating apps, especially for the beginner developer.

I highly disagree, especially since things like the very useful http://www.winprog.org/tutorial/ exist.

It's much better to invest their time on learning programming rather how to possition a button and where to listen for click messages.

Ironically, MS's own "get started with UWP" tutorial involves nearly no code, but lots of messing around with a GUI (without really understanding what's happening and why):

https://docs.microsoft.com/en-us/windows/uwp/get-started/cre...

Win32 is one of the few UI paradigms that it makes sense to invest in. It will never die, and you will get exposed to a whole slate of historical patterns that all the new stuff is based on or built in reaction to.

It will never die but you might not find anyone interested in it. We are shifting to a Marketplace app era and I think that you cannot create a marketplace app with Win32 (I might be wrong here).

Even if you could create a Marketplace app with Win32 api it would be a nightmare to create a responsive UI to support multiple monitor sizes.

I have worked really hard to create responsive UI with Win32 and the result was barely acceptable but with UPF or HTML it's such an easy task, it all come out natural

This is why I wrote the Tron project (https://old.reddit.com/r/TronScript) in batch. It's a huge pain, but batch ALWAYS works and doesn't change, unlike PowerShell v1/2/3/etc. More work, but works on everything from XP to 10 v.whatever.

In batch! The thing that always asks you if you want to terminate the batch job :-) are you familiar with/did you consider WScript? You can write JScript which is a lot nicer and still works on older machines...

Hey, don't kinkshame.

Batch is instant turndown even for thing that I want a lot like this one.

Powershell even limiting to 2.0 which never changes would be way better.

I second this, and also recommend using Cygwin/gcc to build it with. Then you can bypass most Windows horseshit altogether, and maybe just run it on a real operating system under Wine.

Reply on news.ycombinator.com