3 ms·

If I were to develop native Windows app now, I would still go for C-Win32-GDI, instead of sorting through all those jungle of stacks that had been coming and go

If I were to develop native Windows app now, I would still go for C-Win32-GDI, instead of sorting through all those jungle of stacks that had been coming and going in the last 20 years.

zenlot 5y ago
I'd choose Delphi instead for native Windows apps. This is where it still shines.
Koshkin 5y ago
And with Wine you have some hope for portability.
spaetzleesser 5y ago
qt would be a good candidate too.
oneplane 5y ago
Unless you're writing something low-level like a driver or representation engine (game engines or CAD/CAM or something like that), why would you still have to write native Windows applications? I do see how a native application generally behaves and performs better, but it's a whole lot of extra work vs. a less-than-native application. I'd even opt for a generic backend (say, Rust or Go based) and simply having the 'interface' be OS-native.
- gefhfffh 5y ago
  You can develop native windows apps in Rust these days - even through the new old win32 APIs
  - oneplane 5y ago
    Technically anything with a bridge or FFI would be native enough I suppose ;-)
  - topspin 5y ago
    You can, and it's actually more pleasant to deal with than Rust+GTK on Windows, if only for the compile time.
- no_time 5y ago
  Pride in one's craft. It starts to make a lot of sense when you are optimizing for anything other than profit.
- pjmlp 5y ago
  Life sciences laboratory devices, DAW, factory automation, air gaped dashboards, for some examples.
  - oneplane 5y ago
    So essentially the representation engines (specialised science on Windows, DAW on Windows), but factory automation or air gapped dashboards, I doubt either needs Windows or 'native' applications on a desktop? Maybe a Windows-based HMI or something, but other than that I haven't seen any implemented like that. Factory automation at TSMC and the likes is mostly just Java, web and webbased interfaces all in a closed network. Same for most modern logistics factory automations. Classic PLC-based HMI interfaces from Siemens and the likes do still come with Windows as a dependency, but those have normal HTTP interfaces as well. Besides, this is such a niche with so much money going around they hardly depend on the ability to work inside of Microsofts limits. Calls into private APIs galore, hence the limits on OS patches and upgrades that might break those undocumented interfaces...
    - pjmlp 5y ago
      Most drivers for such hardware are based on DLLs or COM, and they aren't going to change any time now.
      - oneplane 5y ago
        As far as I can see most are using the same protocols they always have over the buses they have always supported, no special driver applies. But even then, why limit the end-user application to a Windows desktop native application in C or C++ when you can also just have it run a communication server and do the client-side things in a more universal implementation. Makes for better compartmentalisation anyway, like the example of the closed networks of chip manufacturers. The chip machines and control systems run linux, but the desktops can be anything with a TCP/IP stack and a browser.
        pjmlp 5y ago
- userbinator 5y ago
  It's definitely not "a whole lot of extra work". The same attitude as yours has spawned an entire culture of repulsive inefficiency and egregious waste. Hundreds or even gigabytes of memory for a bloody chat client which still manages to lag noticeably on 2019-era hardware? How is that even acceptable? ...all because of some misguided and incredibly selfish notion that "developer experience" somehow trumps that of however many users there are (and because a lot of this is corporate shit, we have no choice but are forced to use it.)
jcelerier 5y ago
If were to develop a native Windows app 20 years ago, I'd have picked Qt, in these 20 years I'd have relatively simple changes to make and in exchange I'd get portability to many more places and great performance https://www.qt.io/blog/2018/05/24/porting-from-qt-1-0 https://www.qt.io/blog/2018/05/24/porting-from-qt-1-0 I'd do the same today, definitely !
tored 5y ago
I can recommended PureBasic. You can call win32 API directly from PureBasic if you need to. Easy to both build and call static and dynamic libraries. https://www.purebasic.com/ https://www.purebasic.com/
topspin 5y ago
The classic Win32 GDI API isn't the worst thing imaginable. It has been the basis of untold amounts of successful GUI software and it still works, although much of the latest capability of Windows is hard to reach using it. The best GUI development experience I had on Windows aside from that was WTL/ATL. I kept hoping for a long time that this framework would reemerge as a first class GUI platform on Windows. I think Microsoft missed a tremendous opportunity by neglecting it. It actually made writing COM components enjoyable and appealing.

If I were to develop native Windows app now, I would still go for C-Win32-GDI, instead of sorting through all those jungle of stacks that had been coming and going in the last 20 years.

zenlot 5y ago

I'd choose Delphi instead for native Windows apps. This is where it still shines.

Koshkin 5y ago

And with Wine you have some hope for portability.

spaetzleesser 5y ago

qt would be a good candidate too.

oneplane 5y ago

Unless you're writing something low-level like a driver or representation engine (game engines or CAD/CAM or something like that), why would you still have to write native Windows applications? I do see how a native application generally behaves and performs better, but it's a whole lot of extra work vs. a less-than-native application. I'd even opt for a generic backend (say, Rust or Go based) and simply having the 'interface' be OS-native.

gefhfffh 5y ago
You can develop native windows apps in Rust these days - even through the new old win32 APIs
- oneplane 5y ago
  Technically anything with a bridge or FFI would be native enough I suppose ;-)
- topspin 5y ago
  You can, and it's actually more pleasant to deal with than Rust+GTK on Windows, if only for the compile time.
no_time 5y ago
Pride in one's craft. It starts to make a lot of sense when you are optimizing for anything other than profit.
pjmlp 5y ago
Life sciences laboratory devices, DAW, factory automation, air gaped dashboards, for some examples.
- oneplane 5y ago
  So essentially the representation engines (specialised science on Windows, DAW on Windows), but factory automation or air gapped dashboards, I doubt either needs Windows or 'native' applications on a desktop? Maybe a Windows-based HMI or something, but other than that I haven't seen any implemented like that. Factory automation at TSMC and the likes is mostly just Java, web and webbased interfaces all in a closed network. Same for most modern logistics factory automations. Classic PLC-based HMI interfaces from Siemens and the likes do still come with Windows as a dependency, but those have normal HTTP interfaces as well. Besides, this is such a niche with so much money going around they hardly depend on the ability to work inside of Microsofts limits. Calls into private APIs galore, hence the limits on OS patches and upgrades that might break those undocumented interfaces...
  - pjmlp 5y ago
    Most drivers for such hardware are based on DLLs or COM, and they aren't going to change any time now.
    - oneplane 5y ago
      As far as I can see most are using the same protocols they always have over the buses they have always supported, no special driver applies. But even then, why limit the end-user application to a Windows desktop native application in C or C++ when you can also just have it run a communication server and do the client-side things in a more universal implementation. Makes for better compartmentalisation anyway, like the example of the closed networks of chip manufacturers. The chip machines and control systems run linux, but the desktops can be anything with a TCP/IP stack and a browser.
      - pjmlp 5y ago
userbinator 5y ago
It's definitely not "a whole lot of extra work". The same attitude as yours has spawned an entire culture of repulsive inefficiency and egregious waste. Hundreds or even gigabytes of memory for a bloody chat client which still manages to lag noticeably on 2019-era hardware? How is that even acceptable? ...all because of some misguided and incredibly selfish notion that "developer experience" somehow trumps that of however many users there are (and because a lot of this is corporate shit, we have no choice but are forced to use it.)

jcelerier 5y ago

If were to develop a native Windows app 20 years ago, I'd have picked Qt, in these 20 years I'd have relatively simple changes to make and in exchange I'd get portability to many more places and great performance https://www.qt.io/blog/2018/05/24/porting-from-qt-1-0 https://www.qt.io/blog/2018/05/24/porting-from-qt-1-0 I'd do the same today, definitely !

tored 5y ago

I can recommended PureBasic. You can call win32 API directly from PureBasic if you need to. Easy to both build and call static and dynamic libraries. https://www.purebasic.com/ https://www.purebasic.com/

topspin 5y ago

The classic Win32 GDI API isn't the worst thing imaginable. It has been the basis of untold amounts of successful GUI software and it still works, although much of the latest capability of Windows is hard to reach using it. The best GUI development experience I had on Windows aside from that was WTL/ATL. I kept hoping for a long time that this framework would reemerge as a first class GUI platform on Windows. I think Microsoft missed a tremendous opportunity by neglecting it. It actually made writing COM components enjoyable and appealing.