6 ms·

A guide to Windows application development using w64devkit

72 points by petercooper 6y ago

wizzard0 6y ago
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.
- flohofwoe 6y ago
  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 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/ https://github.com/floooh/sokol-zig/)
- FpUser 6y ago
  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
- deleted 6y ago
  [deleted]
sprayk 6y ago
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.
- Iwan-Zotow 6y ago
  Why do you want MS tools? Download LLVM for Windows, it produced native Win binaries, works well, you could use the same GCC flags
- Sindisil 6y ago
  One option would be to use Visual Studio Build Tools (https://visualstudio.microsoft.com/thank-you-downloading-visual-studio/?sku=BuildTools&rel=16 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.
  - auxym 6y ago
    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 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.
    - pjc50 6y ago
      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.
- pjc50 6y ago
  > 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/msbuild-concepts?view=vs-2019 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.
deleted 6y ago
[deleted]
josteink 6y ago
> 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.
- majkinetor 6y ago
  > but 1) it’s still mediocre Ahahahhahhaha, that is insane.
- pjc50 6y ago
  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.
  - josteink 6y ago
    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.

72 points by petercooper 6y ago

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.

flohofwoe 6y ago
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 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/ https://github.com/floooh/sokol-zig/)
FpUser 6y ago
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
deleted 6y ago
[deleted]

sprayk 6y ago

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.

Iwan-Zotow 6y ago
Why do you want MS tools? Download LLVM for Windows, it produced native Win binaries, works well, you could use the same GCC flags
Sindisil 6y ago
One option would be to use Visual Studio Build Tools (https://visualstudio.microsoft.com/thank-you-downloading-visual-studio/?sku=BuildTools&rel=16 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.
- auxym 6y ago
  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 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.
  - pjc50 6y ago
    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.
pjc50 6y ago
> 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/msbuild-concepts?view=vs-2019 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.

deleted 6y ago

[deleted]

josteink 6y ago

> 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.

majkinetor 6y ago
> but 1) it’s still mediocre Ahahahhahhaha, that is insane.
pjc50 6y ago
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.
- josteink 6y ago
  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.