Only if you want to be trendchasing rather than letting backwards compatibility take care of itself... I'm a native Win32 developer, have been one for a few decades, and know quite a few others still using MSVC6 because it's fast and enough for what they do. Takes Long file paths: Azure, OpenSearch, and ~90 other open source projects have to document how to enable long file paths on Windows because the default is a ~…
Cross-compiling binaries for Windows is easier than building natively
141–150 of 349 posts
Re: Cross-compiling binaries for Windows is easier than building natively
#142> Are derived community works, like say the D-language, Dart, or Zig bindings to the win32 API which are generated from those files open source - if Microsoft did not release them as such? Certainly. The source for these bindings is the WinMD file, which is MIT licensed. While it is true that its contents are generated wholly from non-FOSS sources, it doesn't impact end users of the metadata. Microsoft owns the origi…
Re: Cross-compiling binaries for Windows is easier than building natively
#143Now try building a "portable" binary that runs on a version of Linux older than yours.
If you want to build binaries for a distro, build in that distro. If that distro has a Docker image, it's as simple as: docker run -v "$PWD:/src" olddistro:version /src/build.sh $dayjob supports distros as old as CentOS 7 and as new as Ubuntu 22.04 this way. Compiling on one distro and then expecting it to work on another distro is a foolhardy errand. Libraries have different versions, different paths (eg /usr/lib vs…
> Compiling on one distro and then expecting it to work on another distro is a foolhardy errand.
This is why Windows, with all its issues, is still relevant in 2022. I got tired of updating my distro and software stopping to work. If you are on happy walled garden land of the main repository you're fine. When you need some specialized software or something that is not being maintained anymore, good luck. And at the end of the day, people just want their work done.
This is why Windows with all bloat, advertising, tracking, security issues (no click RCE in 2022, wtf) STILL is going strong.
Re: Cross-compiling binaries for Windows is easier than building natively
#144Re: Cross-compiling binaries for Windows is easier than building natively
#145Re: Cross-compiling binaries for Windows is easier than building natively
#146Earlier quoted context omitted.
Doesn't cargo-bundle do that? I haven't tried to use it to generate .msi files, only for iOS/macOS, but it has the feature!
Cargo-bundle was supposed to do that, but only the Mac part was completed. Nobody ever did the .msi output. I've been trying to get someone interested in doing that. That task needs someone very familiar with the Microsoft ecosystem, which I am not. Discussion in Rust tools forum here.[1] [1] https://internals.rust-lang.org/t/cross-platform-bundling/16...
https://gist.github.com/amake/3e7194e5e61d0e1850bba144797fd7...
Inno Setup was the best and easiest thing for me to ever use but when I was building Windows installers for use from a Windows OS.
Update:
Found this Cargo package rust-msi:
Re: Cross-compiling binaries for Windows is easier than building natively
#147For me SDK sizes are showstopper. Mingw packages are probably 100-200 Mb total. To build anything native one has to install Windows (20+Gb in modern version and then Visual Studio 40+Gb). Not so easy to fit it all on an SSD drive. Xcode also have this problem now. 8Gb for Xcode 7 is manageable. But why 70Gb for Xcode 11?
I'm cross-compiling Mach engine[0] with Zig, it ends up being a quite small toolchain to cross-compile a game engine (using DirectX, Vulkan, OpenGL, and Metal on respective platforms) from any OS. The Zig toolchain is: * Windows: 61 MiB * Linux (x86): 49 MiB * macOS (x86): 42 MiB * macOS (arm): 38 MiB Zig provides almost everything that is needed to cross compile to those same targets out of the box, including libc a…
Re: Cross-compiling binaries for Windows is easier than building natively
#148Only if you want to be trendchasing rather than letting backwards compatibility take care of itself... I'm a native Win32 developer, have been one for a few decades, and know quite a few others still using MSVC6 because it's fast and enough for what they do. Takes Long file paths: Azure, OpenSearch, and ~90 other open source projects have to document how to enable long file paths on Windows because the default is a ~…
The 260 path limit is a pain for organizing media. It's not surprising most applications/games store their media in giant blobs instead of just individual files. This makes software updates a pain since it requires users to download the entire blob if you can't diff the blobs or if the diff corrupts the blob due to mismatched implementation versions.
Re: Cross-compiling binaries for Windows is easier than building natively
#149Earlier quoted context omitted.
It's incredibly fitting that all the links on that post are 403 Forbidden
Microsoft has never really "got" the idea of URLs. The only links to Microsoft stuff you should expect to still work properly in a year from learning them are in the form of an aka.ms alias which is publicly advertised . Anything else, maybe it's a brief article explaining a technology you care about, next week somebody replaces that with a video blog of some people who don't really know much about it but are sure th…
Re: Cross-compiling binaries for Windows is easier than building natively
#150Only if you want to be trendchasing rather than letting backwards compatibility take care of itself... I'm a native Win32 developer, have been one for a few decades, and know quite a few others still using MSVC6 because it's fast and enough for what they do. Takes Long file paths: Azure, OpenSearch, and ~90 other open source projects have to document how to enable long file paths on Windows because the default is a ~…
I'm not going to convince you to change your tool chain, userbinator, but for the sake of the discussion: Once you have multiple projects going on, with multiple components, and then those components have a small directory structure themselves, you can easily reach 260 characters. Add to that, if theres data coming from another org, a long file name can be very helpful to keep track of what it is (and don't forget 10-12 characters for a date!). And finally, the nail in the coffin: most users don't think about path names, I struggle to get people to not put periods in their filenames which messes with some tooling, how am I going to convince the guy in finance who gave me this data that he should use short file names? Should I modify the file name and make it untracable?
ETA: The "if you have to ask you've messed up", I don't ask, I expect and then get annoyed it broke. I had 10,000 files collected into a folder. Why can every other program tell me the list of files in an instant but windows explorer crashes (the whole desktop environment) because I opened that folder to see it. I'm not meant to do that? Then why can the kernel, the disk, the file system, and all other programs handle it with ease?