Cross-compiling binaries for Windows is easier than building natively
gist.github.com
gist.github.com
The only current headache is that there's no pure Rust bundler, to make ".msi" or ".msix" installer files.
If you dump the legacy OS stuff, it gets easier.
[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:
I looked at that crate. That lets you read and write .msi files, but those are just containers. It doesn't help you set up the rather complicated contents required. Someone who's into the Windows ecosystem could probably use it to do the limited things cargo-bundler does. The neat thing about cargo-bundle is that it only needs the info from the Cargo.toml file to drive the bundling process. Most Windows installer builders involve manually constructing Windows-specific XML files.
I have set up a toolchain based on Wix, running via Mono and Wine on Linux, for the purpose of packaging some rather complex .msi files in a commercial software project. Has been running on the Linux-based CI servers of that project for 10 years straight now, with the only change having been that the entire chain has been packaged into a Docker container a few years ago when that became fashionable.
I only know about other proprietary non-MS solutions like InstallShield, which also generate .msi files but use their own proprietary way to define the installation process, with the benefit/disadvantage (depending on what you want to do specifically) of being on a higher abstraction level than WiX, which is more or less a direct resemblance of the internal Windows Installer data structures.
That’s exactly how I rigged up building our MSIs at Tailscale.
I tried doing that, and then found that my test suite passes on real Windows but fails on Wine, because it uses APIs which Wine doesn't implement correctly (or at all).
It's rather impressive that the whole Rend3->WGPU->Vulkan chain for 3D graphics works under Wine, because that's all bleeding-edge stuff. It's only that full screen won't work. Wine reports "fullscreen true stub!", so it's something not implemented yet, rather than something broken.
The official dev tools are really frustrating (except the debugger, I like gdb but it kind of sucks with c++)
What did not work for you specifically?
[1] https://nsis.sourceforge.io/Main_Page
[2] E.g.: https://aur.archlinux.org/packages/nsis / https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=nsis
In my enterprise, a big one, I shipped only NSIS installers. Much easier to use, and better user experience also.
It is only a bit more work
https://activedirectorypro.com/deploy-software-exe-using-gro...
The biggest advantage is not having to use different tools for different target platforms.
Unfortunately MacOS is more difficult target than Windows. If anyone has tips for compiling and debugging software of MacOS from a Linux host, please do share.
The post meanwhile seems to be part about open source policy (nasty, but not a technical issue - also including a new-to-me and hard to find on a Google or DDG search fact about the VS gallery endpoints having led to legal threats), part issues induced by 'weird' modern languages not caring to support Windows (as expected?), part Git for Windows not bothering to handle symbolic links cleanly (and the weird admin-only default thing that remained from Vista), and part... concerns where if people would spread the proper way of doing stuff (curl.exe bundled by default for downloads, or long file names being 'weird' - albeit less broken than claimed here) instead of just ranting this'd be fine too... but not really a coherent whole.
Also I don't think Pylance or whatever core extensions being closed source contradicts with the fact majority of VS Code (or vscodium) is open-source. And I don't see anything morally wrong that they want to close source some of their competitive products.
My personal problem with Pylance or ssh tools is that they are not working with VS Code based forks. That means that VS Code is not that open source as it trying to look like. And this is suspicious for me.
This is not true in general. It isn't even true for programming tools. Paid/non-OSS IDEs (JetBrains suite, Visual Studio) are often better in many ways than their FOSS equivalents (Eclipse, Qt Creator, etc).
Other examples: office programs (MS Office vs LibreOffice), digital AV workstations (Adobe suite, Da Vinci Resolve vs Kdenlive, ShotCut, etc), 3D editors (Blender is the one exception here, but Maya is still damn good)...
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 <250MB of disk space, and the self-contained binaries it generates will work on any version of Windows starting at Win95.
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 ~255 character limit.
Personally, I think 260 is long enough and plenty to work with, while at the same time discouraging the ridiculous verboseness that seems to have crept into "modern" software. Then again, I stay away from .NET, VSCode, and the like. I am reminded of this post by Raymond Chen:
https://devblogs.microsoft.com/oldnewthing/20070301-00/?p=27...
"quite a take" f u
it wasn't Microsoft's content to move.
movement to docs.microsoft.com meant giving copyright to Microsoft, and not everyone chose to do that.
And some weren't even alive. Michael Kaplan and his amazing blog about internationalization and Unicode comes to mind - thankfully, other people have archived it: http://archives.miloush.net/michkap/archive/
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 they'll become world experts over the next months and years - and you're invited on their journey, then the blog becomes a wiki, then it becomes an exciting new user-led forum, and then... it's a 404 because they were re-assigned to a different project and all knowledge was destroyed.
Raymond used to be just one of hundreds, maybe thousands of Microsoft bloggers. Then one day Microsoft decided blogging was not on brand and it just blowtorched all the blogs except a few very popular ones like The Old New Thing.
I immediately thought of Teams links.
At least make another URL shortener like teams.ms and pass the URL through it before giving it to me.
I wonder if I it's possible to create a file in Windows named after a MS teams link as it's so long.
Is it so difficult to generate a short UUID?
Zoom does it with numbers.
Google Meet does it better with hyphen separated 10 letters so you can even read it out or just remember for 5 seconds before typing it elsewhere.
nesting windows more than 50 levels deep: https://web.archive.org/web/20110623211503/http://blogs.msdn...
nesting menus more than 25 levels deep: https://web.archive.org/web/20110623211552/http://blogs.msdn...
creating a dialog box with more than 65535 controls: https://web.archive.org/web/20110623211515/http://blogs.msdn...
the maximum number of threads a process can create: https://web.archive.org/web/20110628235212/http://blogs.msdn...
the maximum length of a command line: https://web.archive.org/web/20110707074737/http://blogs.msdn...
the maximum size of an environment block: https://web.archive.org/web/20110623211524/http://blogs.msdn...
the maximum amount of data you can store in the registry: https://web.archive.org/web/20070302025026/http://support.mi... (the live link http://support.microsoft.com/kb/256986 still works perfectly, so here's the view as of ~the post date of the article)
if you have to ask, you can’t afford it: https://web.archive.org/web/20080607185547/http://listserv.l...
You'll see older pc centric game engines use loose files. With the advent of ssds on consoles we might see a return to bunch of files approach as it keeps patches smaller.
Steam and EGS updating handles binary diffing wonderfully. While consoles, not so much. Specifics are NDA of course but I bet any game dev reading will know who I am talking about when I say: "platform x has a horrible diffing algo yet requires approvals for updates over size Y". If I could ship a loose filesystem and get reasonable load times I would just for the update package advantage.
No, packing individual files into archives makes sense on PCs too due the native filesystem usually having a much bigger per-file storage overhead as well as non-negligible open() times - the second is especially true for Windows with "Anti Virus" software installed.
> You'll see older pc centric game engines use loose files.
Some maybe, but packing game assets into archives is as old as Doom and has been the norm all this time.
> Steam and EGS updating handles binary diffing wonderfully.
Steam handles binary diffin now, but it was not that long ago that it re-downloaded the whole changed file.
Doesn't that tie you to a really old C runtime, and aren't security holes often found in the C runtime?
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?
Cross-platform compiling is not a trend, it is one of the only two sane solutions to supporting customers.
The other is browser-based SaaS. But now you have two problems, to paraphrase Zawinski.
* File cannot be moved into a subfolder.
* Folder can be renamed, after which a file contained within it is inaccessible.
* File on a network drive may be accessible by some users, but not others. For example, one user may access the drive with the longer network name, while another has mapped the network drive as Z:\. A filename may exceed the 260 character limit for the first user, but not for the second.
* Cannot delete a folder, because it contains a file with a long name.
My experience may be biased due to using a program that recorded metadata in a filename, taking the majority of the 260 characters available in just the filename, but with the number of failure modes, I still don't think it is reasonable to have such a small limit.
What is the point of the registry/gpedit setting to enable long paths system-wide -- when so much of Windows doesn't support it? File Explorer is really showing its age.
Has any of this improved in Win11?
That's some strange logic - you expect someone wanting to compile things for windows to somehow discover a 24-year-old compiler using some older version of C/C++ and to conclude that, despite modern norms, it still works, is still legally available and still produces working binaries.
And if they don't somehow glean all of the above, you say they're trendchasing, rather than just not knowing and using something two-decades obscure and possibly illegal.
> 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 <250MB of disk space, and the self-contained binaries it generates will work on any version of Windows starting at Win95.
I share your view about the unmatched backwards compatibility of Win32 binaries, but I wouldn't let a 24-year old compiler like MSVC6 near any new project. We are talking about a compiler here that doesn't even support the C++98 standard, let alone all the basic features for writing safe software (stack cookies, _s APIs, smart pointers - just to name a few).
When I needed reliable self-contained binaries and backwards compatibility, I switched to VS2019's clang-cl compiler and ported their libc++. Together with winpthreads from the mingw-w64 project, this enabled me to write software using even C++20 features, but still maintain compatibility down to Windows NT 4 from 1996. If you're interested, it's all documented here: https://colinfinck.de/posts/targeting-25-years-of-windows-wi...
I think the core.autocrlf option in Git is more harmful than useful (for example, it can change file hashes and break something) and should be removed. An option to warn about unwanted \r characters on commit might be useful though.
Nowadays, I am willing to agree with you. It breaks more things than fixes them.
autocrlf = input
Windows was always its separate island, and at least in the past it had a lot of developer mindshare (so more like a whole continent than an island), and from the point of view of those Windows devs, Linux is the odd one out ;)
One common solution is to use scripting languages for build automation that try to hide most of the differences (e.g. Python or Node.js instead of Powershell vs Batch vs Bash), and most importantly there's simply no way around testing on at least Windows, macOS and Linux.
It's not Windows' fault, rather it's NTFS.
Too tired to go find them atm
<https://github.com/Microsoft/WSL/issues/873#issuecomment-425...>
My takeaway from that comment is that there are some important performances issues that apply generally to all filesystems on Windows. Maybe we can partially test whether that's the case by playing with WSL1 on ReFS, ExFAT (if that's even supported, with its limited permissions support, or ZFS, once OpenZFS on Windows stabilizes a bit.
all my cygwin build rules contained turning off inherited perms to be able to compile bigger systems under an hour. e g. https://github.com/rurban/cygwin-rurban/blob/master/release/...
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 original IDL/headers and can choose to license any related work however they like.
I think you meant a GUI application that runs on a version of Linux older than yours.
Any reasonable person doing this would use Musl of course.
Or just compile against an older glibc version. Plenty of tools to setup sysroots for that, e.g. https://wiki.gentoo.org/wiki/Crossdev
Trying to statically link with glibc is a fool's errand.
Not that it is needed for forward-compatible Linux binaries since newer glibc versions are backwards compatible so dynamically linking the oldest one you want to support works fine. Would be nice if glibc/gcc supported targetting older versions directly without having to have an older copy installed but that is a convenience issue.
First I tried to get it to link to a different system library but no package manager is happy with multiple major versions of glibc.
Then I tried MUSL but it turns out the moment you enable MUSL several OpenSSL packages used in very common dependencies don't compile anymore. There was something about a custom OpenSSL path that I would need to specify and a cert file I'd need to package, but I gave up at that point.
The solution was to use a Docker image of an ancient version of Debian with an old version of glibc to build the file. I have no idea how you'd deal with this crap if your version of glibc is even older or if you don't have glibc, my conclusion was "I guess you can't use the usual HTTP crates then".
Oh, and the "just statically link everything" approach is also terrible for security patches because most developers don't release security patches with the same urgency as library developers do. GnuTLS had some pretty terrible problems a while back that were quickly resolved with an update but the most recent version of some binaries online are still vulnerable because the devs chose to statically link GnuTLS and abandoned the project a while back.
Libraries are an enormous pain point for Linux development and even static linking won't always be there to save you. This is one of the reasons some game developers choose to release a "Linux version" of their game by just packaging Proton/Wine with their executable and making sure their game performs well under the compatibility layer. All the different versions of all the different distributions and all the different flavours are impossible to keep up with.
Linux devs have chosen to ship entire Linux core libraries with their applications in the form of AppImage/Flatpak/Snap/Docker to solve this problem. If static linking solved all problems, Docker wouldn't have taken off like it did.
Regardless, it's incredibly complicated to compare linking behaviour between Windows and Linux. Windows has tons of components built into the API (and which is maintained by Microsoft) which you'd need an external dependency for in Linux. Microsoft provides interfaces for things like XML processing, TLS connections, file system management, sound libraries, video libraries, rendering engines, scripting engines and more. If there's a vulnerability in WinHTTP, Microsoft will patch it; if you statically link curl, you'll have to fix it yourself.
Of course many open source developers will statically link binaries because that way they don't have to write platform specific code themselves, but they only need all those dependencies because your average distro is pretty bare bones if you strip it to its core components. If you write cod Linux, you're not even getting a GUI by your base platform, you'll have to provide your own bindings for either X11 or Wayland!
Most third party Windows software I run is some application code and maybe a few proprietary DLLs that the software authors bought. Sometimes those DLLs are even just reusable components from the vendor themselves. Only when I install cross compiled Linux software do I really see crazy stuff like a full copy of a Linux file system hidden somewhere in a Program Files folder (GTK+ really likes to do that) or a copy of a modified dotnet runtime (some Unity games).
The big exception to the rule, of course, is video games, but even those seem to include fewer and fewer external components.
Development becomes a lot easier when you can just assume that Microsoft will maintain and fix giant frameworks like the .NET Framework and the Visual C++ runtime (basically libc for Windows) for you. Microsoft even solved the problem of running multiple versions of their C runtime on the same machine through some tricky hard linking to get the right dependencies in the right place. As a result, most Windows executables I find in the wild are actually linked dynamically despite the lack of a library management system.
As far as the OS offering more - it's true, but not to the extent you describe. For example, Windows does offer UI (Win32), but most apps use a third-party toolkit on top of that. Windows does offer MSXML, but it's so dated you'd be hard-pressed to find anything written in the past decade that uses it. And so on, and so forth. I just went and did a search for Qt*.DLL in my Program Files, and it looks like there's a dozen apps that bundle it, including even Microsoft's own OneDrive (which has a full set including QML!).
Even with .NET, the most recent version bundled with Windows is .NET Framework 4.8, which is already legacy by this point - if you want .NET 5+, the standard approach is to package it with your app.
And then there's Electron, which is probably the most popular framework for new desktop apps on any platform including Windows - and it is, of course, bundled.
"Some application code and maybe a few proprietary DLLs" is how things were back in 00s, but it hasn't been true for a while now.
Heck the designer still has issues to render most stuff on .NET 6.
I assure you, there is plenty static going on in Windows land.
git config --global core.symlinks trueIt's a solution that works well and is used by loads of developers, but it's still comically silly.
Sure, having a nice SDK where you can just specify the minimum vesion you want to support would be nice but who do you expect to develop such an SDK? GNU/glibc maintainers? They would rather you ship as source. Red Hat / SUSE / Canonical? They want you to target only their distro. Valve? They decided its easier to just provide an unchaning set of libraries since they need to support existing games that got things wrong anyway and already have a distribution platform to distribute such a base system along with the games without bundling it into every single one.
I wrote a tool [0] which will take any system and create a cross-compiler toolchain for it, this is what I use to compile for Linux, HP-UX, Solaris, BSD, etc on Linux.
I love my ancient machine and have a few 32-bit apps I need, though I guess old hardware isn't quite the excuse it used to be.
https://dortania.github.io/OpenCore-Legacy-Patcher/MODELS.ht...
All this scope creep takes development efforts away from reaching 1.0 however. If we had more labor, then we could potentially take on more scope. And if we had more money then we could hire more labor.
So if y'all want Zig to support a wider OS version range, we need some more funding.
docker run -v "$PWD:/src" olddistro:version /src/build.sh
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 /usr/lib64 vs /usr/lib/x86_64-linux-gnu/ vs...), and different compile-time configuration (eg openssl engines directory) across distros.
> 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.
Also, it is old enough that it's going out of LTS soon.
As a datapoint, CentOS Stream 9 [0], which was released in 2021, and which RHEL 9 (released in May 2022) is based on, is already ~60% out of date according to repology: https://repology.org/repository/centos_stream_9.
Also: In computer time, 8 years is "very old". That's longer than the "mainstream support" window for Windows 7 was (from 2009 to 2015), and about as long as the mainstream support window for Windows XP (from 2001 to 2009).
[0]: CentOS "Stream" has a different release model and appears to be a bit of a rolling release as I understand it? But that would cause it to be more up-to-date, not less.
Only if you link random libs you find in on the system. The base system libs making up a Linux desktop (glibc, xlib, libasound, libpulse*, libGL, etc.) all are pretty good about maintaining backwards compatibility so you only need to build against the oldest version you want to support and it will run on all. Other libraries you should distribute yourself or even statically link with their symbols hidden. This approach works for many projects.
It is almost always possible to do some relatively simple hacks to make old stuff work, though (LD_PRELOAD, binfmt_misc/qemu, chroot/docker).
This is portable to CPUs with the same features running older linuxes. To be portable to CPUs with fewer features you should specify the CPU family with `-Dcpu=foo_bar` which seems to be the equivalent of `-march=foo-bar`.
Look no further than the hoops you need jump through to distribute a Linux binary on PyPI [1]. Despite tons of engineering effort, and lots of hoop jumping from packagers, getting a non-trivial binary to run across all distros is still considered functionally impossible.
We are not talking out of our ass here - I myself do this for all the software I maintain and just works. Tons of programs are released this way.
It's not that unusual, though, a quick search turns up 1.1k GitHub repositories with `git config core.symlinks true` in their documentation or CI pipelines - including quite popular projects like Ava, Apache Arrow, Solana, Chrome Devtools, adobe-fonts, IBM/houdinID, travis-ci, RabbitMQ, various Google projects & more.
NTFS does support them, however. Is Git just not supporting them properly?
Asking because I doubt e.g. my mom knows that NTFS has symlinks.
https://docs.microsoft.com/en-us/windows-server/administrati...
One is even a professional AAA DirectX gamedev.
I think you misread that line.
I think they misread the line.
(Whether it was right or not, so you don't need to tell me anything about that.)
From my point of view, even when someone is on the correct 'side' of an argument, if they got there by mistake it's still important to point that out. Both fortran77 and CoastalCoder can be wrong at the same time.
Is "I think you misread that line" far ruder than I thought it was?
...surely "I doubt my mom knows" wasn't supposed to be a developer anecdote that I misunderstood massively?
1. You run into it, go "AH, wow, okay, I'll enable Developer Mode"
2. It still doesn't work, you're confused, you Google around a bit more and find out actually you also need to use a Git config option
3. You retry, now the symlinks work, but your compiler fails because "Destination Path Too Long", huh, that's weird
4. You google a bit more, and discover you need to set a registry option. So you do it, but you still get that error..
5. You discover there's another Git option you need to set
And then you're like, hey, what was I doing again? Where did the last hour of my time go? It's death by a thousand paper cuts.
https://docs.microsoft.com/en-us/windows-server/administrati...
My understanding is Microsoft's concern is that applications and OS components not expecting them could lead to security issues. Not sure how real that concern is, but that's the excuse I've heard.
Bufferoverun I guess? I haven't programmed Windows in years, but there's plenty of code I've seen that is pretty much
char path[MAX_PATH];
res = some_func(&path);
Apparently being the best in symlinks hasn't made a difference in the Year of Desktop Linux.
The problem people are running into is that the OS hasn't been designed with wild symlinks in mind and therefore can't guarantee its security principles if any user is able to symlink however they please; if I read the context [1] correctly, it seems like an elevation of privilege is suspected to be very easy to gain if a standard-level user is allowed to place arbitrary soft links on a file system.
I see little reason for Microsoft to enable the "all users can soft link" setting by default. They'd need to audit their OS and userland code to determine where soft links may introduce vulnerabilities in order to change the default and a few developers that absolutely insist on using soft links inside git repos for some obscure reason isn't going to get them to make such an effort.
Microsoft has made enabling the feature a bit easy [2] but I can find very little about the security analysis done for this change, so enabling dev mode might open your computer up to a whole class of vulnerabilities.
I personally don't see a reason to use symlinks in a dev environment, but I suppose *nix developers think otherwise, probably to duplicate files across a source repository for some reason? If your intent is to work together cross platform then there are loads of restrictions you need to deal with. Linux applications tend to trip up over CRLF, every file system has their own stupid restrictions, build tools and shell scripts need to somehow become platform agnostic, you name it.
You can blame Windows for being different but the truth is that Windows is still the most commonly used desktop operating system in the world by a huge margin. macOS and Linux are the odd ones out and there is no good reason why the POSIX/X11 system design is better or worse than Cacoa or Win32; it's a mere difference of convention.
[1]: https://docs.microsoft.com/en-us/windows/security/threat-pro...
[2]: https://blogs.windows.com/windowsdeveloper/2016/12/02/symlin...
https://docs.microsoft.com/en-us/windows/security/threat-pro...
Developer Mode is just a bundle of useful developer-related settings and components that get applied to the device when enabled.
There's a post here about this from the Developer Mode angle with a bit more background:
https://blogs.windows.com/windowsdeveloper/2016/12/02/symlin...
Or do you just want it to be phrased "not supported for users on normally configured systems"? There, then.
Yep.
We backed off to "not supported on normal systems", which is a reasonable change to me.
You mentioning junctions is not even close to a solution, and I am not moving the goalposts. If junctions worked, the complaint wouldn't have been needed from the start. No, this is about actual symlinks, not a similar feature that can do 5% of what symlinks can do.
Windows, oh bummer you need special permissions to be able to call it.
The feature is there and supported.
However using symlinks just isn't a thing in the Windows culture, people use at most Shell shortcuts.
Windows is horribly hard to learn. In a day, i learned how to create file, directories, change the stats on those, execute diff and patch, an do weird string modifications with grep and cut (and learn to commit and push with git). First day on an UNIX machine. First work week on a windows machine (at that time, i had already built a LFS): we have those two project with two different version of (proprietary JS front framework) and (weird php framework). Those don't use the same version of mycrypt.dll (and others, but this one i will remember for at least two dozen year). With the support of non-intern engineers including a windows DBA, it took us a week to manage to install the two different versions.
A week prior, i was linking to a previous version of Ruby for my RoR app (it was around 2013).
But since, i really respect windows sysadmin, they are the best of us. I will just never, ever want to work on a windows server again. I like learning, but putting that much effort for this little rewards? not worth.
Sorry for my rant, I had to get it off my chest.
"CWA, Microsoft Announce Labor Neutrality Agreement"
https://cwa-union.org/news/releases/cwa-microsoft-announce-l...
Sorry to be this way, but I'm refreshing my memory about CBT today:
Over-generalization: Make a comprehensive, negative conclusion that is beyond the current situation.
Labeling and Mis-labeling: The extreme form of overgeneralization. Use fixed, comprehensive, and emotional language to label yourself or others.
Disqualifying the Positive: Unreasonably believe that positive experiences, behaviors or qualities do not count.
Jumping to Conclusions: Making a conclusion before having all the evidence.
Emotional Reasoning: Draw conclusions from your own feelings, because what I think is what the facts are.
I loved .net back in 2003 or whatever. Then I never got to use it for years because I was on unix land. It is now open source and multi platform.
They attacked open anything with all their might (and they were fucking mighty) and the enemy still flourished.
Let them come again. If the new strategy is to pump high quality software out in the open, I hope it becomes a long and bloody war.
when, exactly?
in the 90s-2000s they were always a poor imitation of Borland's
and from the 2010s to today JetBrain's tools blow them out of the water
VSCode is also very popular. I couldn't find any good statistics comparing different text editors, but atom is sunsetting this year, and VSCode continues to grow as some anecdotal evidence.
Visual Studio is still a great IDE for C++ imo. CLion is the only other big IDE for C++ that I've had suggested often.
C# is ranked #9 in github usage[0].
I would consider these "great developer tech", and their popularity seems to confirm that.
Edit: DirectX is also a pretty big deal since afaik it's the only way you can make an Xbox game. I don't have enough experience to say whether DX is great developer tech or not though. I often hear how horrible Metal is more often than I hear negativity about DX, but that's just my experience.
[0] https://madnight.github.io/githut/#/pull_requests/2022/1
but great? absolutely not
and as someone who's uses both: VS without Resharper is still a decade behind Jetbrains' IDEs
And even Java it is debatable, since JetBrains would rather sell CLion licenses than support some of the stuff Netbeans and Eclipse have been doing for 15 years regarding mixing Java and C++ development on the same source base.
When is InteliJ going to have an incremental Java compiler by the way?
also, apple showed us how to do this. build the right thing for today and use virtualization to support yesterday until it can be updated. all software is living these days anyhow.
Personally I use https://github.com/mstorsjo/llvm-mingw's releases directly which does not require MSYS but that's because I recompile all my libraries with specific options - if the MSYS libs as they are built are good for you there's no reason not to use them.
This is a Microsoft issue, not a Windows issue.
The Windows SDK is not just a few C++ headers and a bunch of lib files to link against. It has a huge surface area. The documentation and toolsets assumes all API calls from Windows 3.1 APIs to UWP to be available.
The SDK download (ISO format) is 1.1GB in size, requiring a total of 4GB of disk size to install (whether this includes the size of the installer itself is unclear). Big, but not unavoidably so, and you can pick and choose some features. It bundles debugging tools, the application identifier, a certification kit and MSI generation tools along with its headers (which seems fair to me); less than 1GB of extra kit on top of 1.8GB of headers and libraries you probably want as a Windows dev anyway. Just the headers won't leave you with a working dev environment even if you bring your own debugger.
Unlike what some developers seem to think, you don't actually need to download Visual Studio to get the SDK, you can also download it separately from the website [1]. Pick the ISO version and extract the CAB files yourself if you want to manually pick and choose your files.
The SDK ships as an installer but that just makes sense. Ubuntu ships their headers in DEB files as well, for example. You want to be able to add and remove these packages as you upgrade or downgrade your target API levels without having to manually set up a file system hierarchy.
As for non-GUI interaction: `WinSDKSetup.exe /quiet /ceip off /features DesktopCPPx64` will install only the necessary headers and libraries for x64 C(++) development in the default location without sharing data with Microsoft. Found this command line with `wine WinSDKSetup.exe /?`. You can also add, repair, and uninstall packages with the same installer.
[1]: https://developer.microsoft.com/en-us/windows/downloads/sdk-...
Also I advise to learn about the headless installation flags for Microsoft products.
But genuinely asking, how else would you 'label' VSCode?
"A free and open-source code editor with some optional components that are proprietary"?
As a consequence, many Swift libraries only focus on macOS, just like many dotnet libraries focus on Windows (though recent efforts have improved that situation). You can probably get a lot of them working on Linux as well and if you use Swift for command line tools or web applications. I suppose you can probably run the most important tools cross platform, but the non-native ecosystem is clearly a second class citizen.
The big difference between XCode and VSCode is that Apple doesn't claim XCode is open source; also, XCode is more comparable to Visual Studio than VSCode in terms of SDK integration and preconfigured tooling.
Huge parts of the Darwin kernel are actually publicly accessible while Microsoft only provides kernel sources under NDA in things like education projects. Unless you count the WinXP source code leak, that is.
C# is sort-of mostly open source-ish except that debugger features are closed and the community has little say in its development.
Apple did in fact put effort into making Swift cross platform, as outlined here[1]; though their intention is that Swift programs use the system runtime on macOS/iOS/iPadOS, they put the effort into making a base layer freely available for other operating systems to gain some portability.
I'd personally argue that Apple and Microsoft are similarly if not equally open in their development, but Microsoft advertises itself much more "open source" than Apple. Apple's approach of "you can look but you can't touch" is a lot more explicit and their supposed openness comes up in fewer marketing materials.
Personally, I don't have major issues compiling things on Windows for other platforms (macOs, Win32, Android, Linux). Only awkward thing is designing UIs
Symlinks are a premature optimization in my book, or worse, bad design. On the user level, shortcuts are often the better solution, because they allow arguments to be passed in on the command-line.
This story is really about the arrogance that is as abundant as it is inappropriate in linux world. Never have I heard of dependency hell or broken systems on Android, yet geriatric linux always needs the help of an administrator.
The only place where linux still has some merit is on the server, where its classical but aging mainframe concepts still have some life left in them.
From a practical point of view, I find \ to be a much more suitable directory separator than /, for the same reason I think Microsoft's choice for blacklisting characters like ? and : from file names is silly. There are real world use cases [1] for adding the / to file names so it shouldn't be excluded!
Microsoft has used the / for command switches since its inception, based on the way the DECS TOPS-10 (1970) used linker flags; with / already taken, they chose the Next Best Thing which is perfectly fine. When Unix came around a year after the TOPS-10 they used a forward slash for directories for some reason but there's no way one is better than the other.
For what it's worth, Windows accepts forward slashes. Since Windows 1.0, actually, all the way back in 1985. Try it for yourself in your browser[2], open notepad.exe and save a file in A:/test.txt. Your path separator may be represented differently, but / works perfectly fine.
Fun fact: in some locales (Japanese, for example) your path separator isn't even a backslash; the path separator is actually rendered as 0x5c, which corresponds to the Yen symbol in Japanese locales of Windows. In Korean locales, it'll show up as the Won symbol and you'll probably find many other path separator characters in other locales that existed way back in the console code page days.
[1]: https://answers.microsoft.com/en-us/windows/forum/all/forwar...
There was even an option (in CONFIG.SYS) to alter the 'switch character', which then also caused a lot of command line tools to accept '/' for paths. That option was eventually removed from the config file, but the underlying API retained until quite late. Maybe it was WinME's version of DOS which disabled the API.
Despite all of that, the handle based Int 21 file APIs always supported being passed '/' as a path separator, and it was often accepted by some apps.
DOS based 'C' source code often used "#include <some\\path\\file.h>", however many compilers also simply accepted "#include <some/path/file.h>", probably just as an artifact of the obvious implementation. This wasn't well known, so lots of DOS based 'C' source used '\\' in includes, plus also at the file API level.
[1] https://mxe.cc/
https://www.kylheku.com/cygnal/
You compile in the Cygwin environment where you have all the usual tools. Then shipping the program with cygwin1.dll from the Cygnal project gives it native-like behaviors.
Coding in linux machine is 10000x easier than Windows.
Every time I program on another system I miss Visual Studio.
Have you tried gaming in Proton?
warning: LF will be replaced by CRLF in src/au/policy/dao/EmailQueue.javaXcode also have this problem now. 8Gb for Xcode 7 is manageable. But why 70Gb for Xcode 11?
[0] https://visualstudio.microsoft.com/downloads/#build-tools-fo...
Maybe a decade ago, but SSDs are so much cheaper per GB nowadays. Around $0.11/GB. Pretty sure that's cheaper than the first 1TB HDD I've owned.
I don't really think that the toolchain is to blame for that one.
M1 is very impressive. But I hate macOS as much, if not more than, you hate Windows. My Threadripper makes me very happy.
I have no problems with external drives. Is this a Mac thing too?
32 years ago as a fresh out I got a government job with an SGI box with an enormous monitor. I stare in wonder at the future, right now. It sure doesn't look like happiness.
[0] ...but with frequent travel?
My work stack is tight on 32gb (yeah, it is what it is), that simply wouldn't fly for me. 8gb, especially with all the memory used by the os on MacOs, there's just no way.
Can you please tell that to my IT department which refused to issue me a Linux laptop for 1 month, then took two months to put the order in... I had to get an executive (President of R&D) at the company to harangue IT... I still haven't seen it, apparently they are trying to install the standard "employee spyware" package on it.
Jesus. I have an executive level officer in the company that has my back and you're telling me to quit? Utterly horrible advice.
I believe you mean 256GB.[0] Unless you meant to say 14" or 16" MacBook Pro, in which case the base spec is still only 512GB for either of them, not 1TB.[1][2]
For the prices Apple is charging, I wish they would make 1TB the base spec... but Apple Silicon is so good that the machines sell like hotcakes anyways.
[0]: https://www.apple.com/shop/buy-mac/macbook-pro/13-inch
If that's out of reach im not sure how you're powering your dev machine.
> A 1tb M.2 drive is what... £70?
To be contextually fair, Apple charges $400, and the storage isn't replaceable. Who runs their editor off of an external drive? I imagine the number is very small.
Although, on my machine, Xcode only seems to be taking up 17GB, not 70GB.
* Windows: 61 MiB
* Linux (x86): 49 MiB
* macOS (x86): 42 MiB
* macOS (arm): 38 MiB
* Windows: 7 MiB (updated D3D12 headers & libs)
* MacOS: 112 MiB (almost all frameworks provided by XCode, for x86+arm+iOS)
* Linux (x86): 22 MiB (x11/wayland headers & libs)
* Linux (arm): 15 MiB
* GLFW
* Dawn (Chrome's WebGPU implementation)
* The DirectX Shader Compiler (a fork of LLVM)
* Freetype and HarfBuzz
All from source, cross-compiled to every OS. Plus with Zig you can link+sign macOS binaries from Linux and Windows (AFAIK that's not possible with a regular C compiler, but maybe that's changed recently?)
Many of the high level categories, like Web Development,contain features you'll probably never use. If you're concerned about file size you can do a custom install to get a very lean install.
That being said, I would still recommend a Windows VM be allocated a 120Gb drive.
It was annoying for me because part of the reason I wanted to try Rust on Windows was specifically to avoid multi-gigabyte C/C++ toolchain downloads. I bet the actual compiler and linker aren't that big, so I kind of wonder where all those bytes are going...
Aside: I see a sibling comment mentions Zig. While I haven't really explored Zig, the tiny single-binary download was a breath of fresh air. Go also had a quick and easy download, but I wanted a language without a garbage collector.
> Not so easy to fit it all on an SSD drive.
Professionally, no excuse. As an open source or otherwise unpaid pursuit, a 250GB SSD is about $45 on Amazon right now. That more than comfortably fits your 60GB estimate, with plenty of room to spare.
It's easy to forget that there are billions of people for whom $45 is a massive investment, and that SSD isn't so conveniently available even if they have the money.
I know I got into programming on a mix of graphing calculators and thrown out PCs, and I also distinctly remember having to work around the download sizes of tooling because I was using really crappy internet.
I don't think it's unreasonable for the poster to wish that they could build useful binaries without 60GBs of downloading and storage...
Here's a hint: if they had the budget and availability they'd just get a bigger SSD and not write that comment.
-
Obviously, due to some aspect of their circumstance, be it availability, cost, download speeds, etc. the size of the toolkit is problematic.
I mean there's no intrinsic size for a development toolkit, but I don't know anyone who'd say 60GBs of data is a small development toolkit when as others have pointed out, there are older versions of the same Windows toolchains that still complete the same function and manage to take a fraction of the space...
This whole assuming everyone is destitute is getting rather tiring.
But yeah, seriously woe is you having to momentarily imagine some people are poor or have trouble getting access to tech.
I'm from Ghana so I guess it's not as onerous to imagine people don't live the exact same life I do in the US.
So those people can use whatever hardware they have available to them and not buy the SSD. The parent specifically said it was hard to fit on an SSD, so I assumed they could buy one based on that
> I know I got into programming on a mix of graphing calculators and thrown out PCs, and I also distinctly remember having to work around the download sizes of tooling because I was using really crappy internet.
Graphing calculators, and raspberry PIs (and other various low power devices) are still widely available for people to learn and experiment with. Internet speeds are still a problem in many places but ay some point the software has to be delivered to you, and as I mentioned previously the actually install sizes are not 60GB, and the downloads are significantly smaller (a windows 10 iso fits on a 4GB usb)
> without 60GBs of downloading and storage...
Firstly, it's not 60GB - see my previous post about how much space it actually takes up. It's closer to 30GB. Secondly, if you don't have 30GB of storage of any kind available to you on a computing device,then sure, meanwhile anyone running a machine bought in the last 15 years will have that space available to them.
Let me say it again, 60, 30, even 10GBs, is a lot when there's tooling from the same company, that still make similarly functional binaries, that took 342 MB.
You don't need to keep obsessing over "how dare this person with limited resources use an SSD!", like I said you run into similar issues with just downloading the stuff.
Again, forest for the trees.
-
Instead maybe you can sit back and just ask "why the bloat over time"?
And the reality is likely: "because no one optimized for it". Because for them lots of fast storage and internet speed are no problem
That line of reasoning maybe allows you to see things from a different prospective and break some assumptions about end users.
Isn't that more useful than browbeating some random for not having 30GB free on their SSD?
Would love to see a breakdown of where that space is going. FWIW IntelliJ takes up 2.5GB, and honestly, even THAT seems like a lot to me.
> even THAT seems like a lot to me.
That's a little silly - what is an acceptable amount in that case. The JDK on its own is about 700MB (that's a guesstimate based on last time I installed it sorry).
25GB is enormous. 2.5GB is enormous. Consider that the core value of this software is text editing. Consider that not long ago people were buying PCs with perhaps 10MB of hard disk - or even no hard disk at all (e.g. the Apple IIe). Windows XP and Office 97, for example, were (if memory serves) less than 1 GB total. FoxPro for DOS was something like 4 megabytes - and FoxPro was a form builder plus relational database. Consider that with a thoughtful use of resources and an eye toward minimizing attack surface, you can put a fully functional http/s app server in a 1.9MB package (redbean).
These sizes are silly, and they should give you pause. The space is cheap, yes, but the attack surface is not.
Don't be reductive - just because your linux hides those costs directly in /usr and /var it doesn't mean those things don't exist.
> Consider that not long ago people were buying PCs with perhaps 10MB of hard disk - or even no hard disk at all
Not that long ago in history, but an absolute eternity ago in computing terms. I have a direct internet connection to my home that is faster than the read write speeds of those computers.
> Consider that with a thoughtful use of resources and an eye toward minimizing attack surface
Attack surfaces have changed significantly since people were buying 10MB hard drives - you cannot write applications with the same security considerations from that time.
> you can put a fully functional http/s app server in a 1.9MB package (redbean). The space is cheap, yes, but the attack surface is not.
Firstly, redbean is the absolute extreme example of minimalism and portability. It's not "normal" it's an incredible feat of engineering frankly. Nginx isn't much bigger (~5mb) and caddy is bigger but still small (30Mb). The big difference between these and IDEs is that web servers dont provide client interfaces. For user facing tools they rely on web browsers to render html and interpret JS, so to make a comparison it's only fair to compare redbean + chrome to a Windows SDK install for example.
This is a utility that fixes a lot of the cross-compiling issues for windows by giving you a portable, unfucked naming, and not-massive SDK. It's the same SDK you get when you install MSVC but it's only a few hundred megs and the names are consistent even with all of Windows' fucked up tooling.
The only caveat is you need to provide your own compiler, in this case clang is often the best option.
More people within the MS ecosystem should understand this.
What are you proposing will become the primary desktop OS? Some Linux flavor of the month? MacOS? Neither seems at all likely in the foreseeable future.
I've come to realize while there may never be a "year of the Linux Desktop," there will likely be "years of Linux Desktops" -e.g. Ubuntu, but then also SteamOS, ChomeOS, maybe Android if you're being REALLY inclusive, etc.
on the stackoverflow survey windows is 41.2%: https://insights.stackoverflow.com/survey/2021#most-popular-...
20 years ago that would have been 95%+
and its market share for developers is way, way, way less than its share on desktop (which was my point)
There are plenty of other workloads and platforms to target.
Desktop, mobile devices, IoT, medical, game consoles, infotainment, unikernel, serverless....
The only places that Windows seems to persist are developer markets where tooling choices are limited to Windows (games, medical, embedded) or corporate standards dictate tooling.
Indeed and trying to use UNIX for mobile apps won't bring you far.
> The only places that Windows seems to persist are developer markets where tooling choices are limited to Windows (games, medical, embedded) or corporate standards dictate tooling.
The remaining 99% of the market where UNIX GUIs don't matter.
Also ios and android are unixes too.
Android uses the Linux kernel, nothing on the userspace is UNIX. Tomorrow it can use Fuchsia's Zircon and no one will notice.
I cannot find any reference to Objective-C, Swift, UI Kit, CoreData, Metal, OpenGL ES,... on POSIX standard specification.
"POSIX has become outdated", page 6
https://www.usenix.org/system/files/login/issues/login_fall1...
https://gs.statcounter.com/os-market-share/desktop/worldwide
Think MS teams/Office365, Linkedin, Gaming, Github, etc. These are platforms they are interested in controlling and deriving revenue from.
Windows is the afterthought.
Let that sink in...
That's a very bold statement that I suspect is far from true.
'Let me just exclude an entire multi-billion-dollar industry to cherry-pick examples to make my point sound stronger.'
Yeah, no; Windows isn't going away.
This is not even true. Due to limited resources they wanted to cut scope of what the .NET 6 update included and they thought that it would be okay to delay the dotnet watch feature because most people would still have hot reloading from using Visual Studio.
The PR for bringing back the hot reload code was merged 3 days after the PR for removing it.
https://devblogs.microsoft.com/dotnet/net-hot-reload-support...
It is absolutely true. The CLI-first `dotnet watch` was pretty much done (I was using it in preview for months beforehand), and it was cut to promote hot reload as a Visual Studio feature.
Source: I'm the person who raised the initial GitHub issue about the dotnet watch change, and I talked to multiple Developer Division employees off the record. It was a deeply unpopular move that came from the top (Julia Liuson).
If you want a source from the .NET team, Miguel de Icaza has since quit Microsoft and is able to be more open about what's going on: https://twitter.com/migueldeicaza/status/1537178691218046976
Even during the dotnet watch drama, he was willing to endorse a very critical take at odds with the public line: https://twitter.com/migueldeicaza/status/1451902388290392073
That disappoints me. I would prefer if they would just be honest and say that for the time being they would only support it in Visual Studio.
>to endorse a very critical take at odds with the public one
Interestingly enough the article mentions that Microsoft has been underfunding Omnisharp and VSCode has poor C# support. The first link you gave talks about how Microsoft is now working with Omnisharp to improve C# support.