undefined | Better HN

0 pointsyndoendo6mo ago0 comments

When producing cross-platform software I find creating it on Linux first to be the most cost effective. Porting it to macOS has the least resistance. Windows is where it cost more time and code to release.

macOS, Linux, and BSD treat CMD and GUI applications the same while Windows separates applications. Window's two type of application approach brakes the ability to use STDIN and STDOUT for logging and other useful means. Simple debugging of `./app > app.log` does not work on Windows with `app.exe > app.log` with GUI applications. The Windows variant needs a specialized logging system and more boilerplate code.

Windows also has one of the worst automation system when it comes to solution deployment. One needs to create custom mouse and keyboard emulation scripts to automate the installation of 3rd party applications when their installer does not support silent mode. AutoIT helps me with this greatly.

0 comments

kid646mo ago

Windows does have quirks: MSI installers, Inno Setup, NSIS, and custom EXEs may or may not support silent mode. When they don’t, automation is ugly (AutoIt, AutoHotKey).

But Windows also has strong automation tooling: PowerShell, WinRM, Chocolatey, Winget, MSIX packaging. These provide far more than “mouse and keyboard emulation.”

So your statement ignores the modern ecosystem and overstates the weakness.

yndoendoOP6mo ago

Please note, you are assuming I have the ability to control the version of Windows the product lives on. Some products still have to support up to Windows XP.

Also the PowerShell is actually broken. I can use standard network powershell commands that brake the OS applied to network interfaces. Currently waiting on a laptop with bare metal Windows installation to verify if those sanitized PowerShell commands are crashing the VM or Windows itself.

.NET for the longest time was broken with _NetworkInterface.GetAllNetworkInterfaces()_ only returning enabled NICs. This was finally fixed in .NET 9. Work around his to go WIN32 custom coding when older .NET must be used.

.NET WPF touch screen event messaging system is also broken where it would latch depending on how the finger is swiped off a button. Had to dump that and go with WIN32 as work around so that bug didn't have the capability to crush someone's appendage when being used in machinery.

The registry system the OS is built upon is flawed. It does not have well defined layout such as a configuration file.

Joker_vD6mo ago

> Please note, you are assuming I have the ability to control the version of Windows the product lives on. Some products still have to support up to Windows XP.

It's what, 6 different versions of Windows, with quite clearly defined API "eras"? For Linux, you have just a huge ball of mud^H^H^H distros each of which has (or doesn't have) who knows versions of what, but of course, there you can just give out a .tgz with source code and say to your users "it's your problem now to build it for yourself since you're using Arch".

p_ing6mo ago

Hard to tell with a config file.

j / k navigate · click thread line to collapse