A guide to Windows application development using w64devkit | Hacker News Reader

A guide to Windows application development using w64devkit

nullprogram.com

72 pointspetercooper20 comments

> Windows’ standard command shell is cmd.exe. Unfortunately this shell is terrible and exists mostly for legacy compatibility. For users who regularly need a shell, the intended replacement is PowerShell. It’s a significant improvement, but 1) it’s still mediocre, 2) sticking to POSIX shell conventions significantly improves build portability, 3) unix tool knowledge is transferable to basically every other operating system.

Powershell Core is actually available on quite a few posix-platforms and thus actually portable.

Obviously you’ll introduce a non-standard build-time dependency on Unix-platforms, but by adopting it at least you can slowly ween your Windows-only stuff in a generally more portable direction.

> but 1) it’s still mediocre

Ahahahhahhaha, that is insane.

Everywhere I've worked with Windows build systems I've got people to agree to transition their batch files to Python, which even without the portability question has much better fail-early error handling.

I guess it depends on the team and thing being delivered.

Powershell is built on .NET and shares the same types and BCL.

If your team is a full .NET team, Powershell might actually be easier to transition to than Python where everything is going to be new or different.

I wonder if a similar toolkit could be assembled for the GUI apps using Zig, Nim or some other fancy new C-like languages plus a minimalistic UI wrapper.

Not quite as "radical", but I did something in that direction, a minimal "starter kit" for developing Dear ImGui applications in C99:

https://github.com/floooh/cimgui-sokol-starterkit

It needs the system's "default compiler toolchain" and cmake, but other then that, there are no external dependencies, and I tried to keep everything as simple as possible (even the CMakeLists.txt file).

All the dependencies (Dear ImGui, cimgui and the Sokol headers for cross-platform wrapping of the platform-specific window systems and 3D-APIs) are bundled right in the git repo.

Zig and Nim are sort-of "in progress" (for instance, see the sokol-zig bindings here: https://github.com/floooh/sokol-zig/)

If you want to build powerful rich native self sufficient GUI apps on Windows:

Get Lazarus IDE for Windows. The language is highly advanced Object Pascal

For the same thing but C++ you can get Ultimate++ IDE.

Either will produce single exe file.

Deployment in either case is just copy exe and have at it

I want a doc like this, but targeting MS toolchains and libraries. gcc/make/bash/vim are already on my toolbelt regardless of OS I'm using. I've tried to get a build system going a few times in MS land, but I'm too used to the relative simplicity of gcc and make files and find I have little patience for what feels like massive overkill for building simple command line tools.

Why do you want MS tools?

Download LLVM for Windows, it produced native Win binaries, works well, you could use the same GCC flags

One option would be to use Visual Studio Build Tools (https://visualstudio.microsoft.com/thank-you-downloading-vis...).

You could stick with makefiles by using nmake. It's not nearly as full featured as gnu make, and both cmd and PowerShell are much different (and less powerful in the case of cmd) to bash. Still and all, I've made it work quite well in the past for the Windows build of a library I was responsible for in my former day job.

Another option would be to use cmake as your build tool and let it generate ninja, msbuild, or nmake scripts for you. It's not nearly as bad as it was in the past (nor as bad as some might lead to to believe). Worth a try, anyway.

There's also the option of going in .NET/C# land with the cross platform dotnet SDK (previously known as .NET Core): https://dotnet.microsoft.com/download

It's a CLI based full blown SDK including compiler, package manager and build tools, and it's cross platform.

I love C# and am very impressed with dotnet, but it still has a few limitations - to make it portable you have to ship the runtime with the application, it's not a ""real"" AOT compiled binary. And like all "portable" environments you quickly realize that some of the key native APIs aren't in the portable subset.

> I've tried to get a build system going a few times in MS land, but I'm too used to the relative simplicity of gcc and make files and find I have little patience for what feels like massive overkill for building simple command line tools.

Embrace the target: use Visual Studio (community edition)

You can still write in vim if you want, you just tab over and hit F5 when you want to run.

MSBuild has a steep learning curve, but I've recently managed to climb it using https://docs.microsoft.com/en-us/visualstudio/msbuild/msbuil...

Coming from make, a make target is a msbuild "item". Variables become properties. Build steps are "tasks" - generally you use the builtin ones.

VsVim is pretty good vim emulation for Visual Studio.

> You can still write in vim if you want, you just tab over and hit F5 when you want to run.

or just use cmake with nmake or ninja generator if you are that hellbent on using cl.exe

I'd like to ask the opposite question of this thread: why is everyone so hellbent on not using the Microsoft tooling?

Portability is more realistic with portable tooling.

Portability

it is really different...

I'm using LLVM on Windows - native binaries, calls to clang and clang++ with the same options as gcc.

So LLVM+cmake+ninja works reasnable well for medium sized project

cmake is much more sane imho. And works everywhere. I have nightmares of msbuild.

I wrote one [1] a while ago.

[1] https://akr.am/blog/posts/a-guide-to-compiling-programs-on-w...

Reply on news.ycombinator.com