This and great backward compatibility. I still can make app targeting Win2000 and it will run on Win2000 onwards (Win10 and Win11 included.) Unfortunately, its starts to fall apart...
I guess they finally think they captured enough "value" with Windows so there is no need to keep every subsystem maintained. It must be very expensive to keep a 20+ year developer to sit in a basement room writing code for some feature that does not generate much revenue. Sad truth. TBH I'd love to learn those subsystems and do it for free.
No. You cannot even do direct compilation on the same host and target with clang only.
LLVM doesn't come with the C library headers (VCRuntime) or the executable runtime startup code (VCStartup).Both of which are under Visual Studio proprietary licenses. So to use Clang on Windows without Mingw, you need Visual Studio.
I use MingW without any extra libs (no msys), it just uses the ancient msvcrt.dll that is present in all Windows versions, so my programs work even on Windows 2000.
Additionally the cross-compiler on Linux also produces binaries with no extra runtime requirements.
But that's the point, I don't want the same style executable as Visual Studio. Having to distribute bunch of DLLs and having worse compatibility is pretty bad.
A major part of the incompatibility with older versions of Windows is just because newer VS runtimes cut the support artifically. That's it. Many programs would otherwise work as-is or with just a little help.
yeah, you can get away with this now a days because Git itself installs 2/3rds of the things you need anyway. You just need to finish the job by getting the package and putting the binaries in your git folder. Bam! mingw64, clang, what ever cc you need. It all links to standard windows stuff because you have to tell the linker where your win32.lib is. But this is true no matter the compiler, it's just Visual Studio supplies this in some god awful Program Files path.
MSYS2 is repacked Cygwin though. It is literally the same codebase compiled with slightly different flags. You need a full Unix environment for Bash to run, not just Mingw toolchain. The difference is Cygwin aims to create a full Unix system while MSYS2 just enough development environment to run bash, make etc to build native Windows programs with Mingw.
Git installs its own Mingw and Msys2 stuff but mostly compiled for a Mingw environment so they consume Windows paths natively instead of using MSYS2/Cygwin path conversion. That's why when you have mixed PATH variable all hell breaks loose with Git.
I do appreciate it as a daily user of MSYS2. However the bigger thing that enabled them is indeed Cygwin project since it unlocked the path to build things that are using strict Unix tooling. autoconf, Make, bash etc cannot run under a pure Windows environment. They are too dependent to the underlying system being a Unix. To use pacman, bash and make in MSYS2, you need msys-2.0.dll. Even they cite Cygwin's URL in the runtime package [1]. And they basically patch Cygwin to enable this [2]
Without Cygwin enabling the path, it wouldn't be possible to build GCC for Windows without completely changing its build system. It would be a DOA fork while Mingw and PE32+ support is a part of GCC nowadays.
The nice and genius part of MSYS2 is that it is there to primarily encourage you to develop native Windows software that has better cross-platform behavior rather than Cygwin alone. If Microsoft made a better, free of charge C compiler in early 2000s that is adhering to the standards better, we wouldn't probably need Mingw to build cross-platform apps. Now MSVC is still free of charge for only open source and individuals.
They all have to use MSVCRT or UCRT to stay compatible with other Windows programs and APIs like COM. And AFAIK nobody has developed a C library that's purely dependent on Win32 system APIs (it is possible just really hard). The difference is that Cygwin is trying to create this semi-isolated Unix environment to programs to think they are running under a complete Unix system like Wine does.
MSYS2 is there to just provide the basics so you can develop programs that are Windows native but use some of the tools that have really strong Unix dependence like shells or Make. They depend on the existence of syscalls like `fork` or forward slash being the directory seperator.
It was not clear what the parent commenter was addressing; I was under the impression they meant 'compile against the MSYS2 environment', which is broadly Cygwin, yes, which should not be forced onto a user.
Okay, but that just seems to be perpetuating the misunderstanding of what MSYS2 is intended for.
It gives you a *nix-like shell/dev environment and tools, but you build native software that runs on Windows systems that don’t have or need to have all/parts of MSYS2/Cygwin installed.
I built a network daemon using the MSYS2 CLANG64 environment and llvm toolchain on Windows 10.
Windows 7 x64 users could download the compiled single-file executable and run it just fine, so long as they installed Microsoft’s Universal C Runtime, which is a free download from Microsoft’s website.
I get your point. Although my point is that there is actually zero need for MSYS at all for this, even as a developer, and especially not with the 'CLANG64' environment. These binaries themselves are built to run in the MSYS2 environment This is how I cross-compile from Windows... to Windows with LLVM-MinGW[1]:
I think you have it backwards, but I may misunderstand what you're saying.
I'm certain I haven't misunderstood the point of MSYS2's CLANG64 and other environments.
> These binaries themselves are built to run in the MSYS2 environment
I'm not sure if you're referring to the toolchain binaries or the binaries one produce's with them.
The CLANG64, etc. environments are 100% absolutely for certain for building software that can run outside of any MSYS2 environment!
You can, of course, build executables specifically intended to run inside those environments, but that’s not the primary use case.
> (gci Env:PATH).Value.Split(';') | sort
I don't want to use PowerShell or Cmd.exe when doing dev stuff on Windows. I want to do CLI work and author scripts in and for modern Bash, just like I would for Linux and macOS. I want to write Makefiles for GNU make, just like...
Now, sometimes there are bumps and sharp edges you have to deal with via `if [[ -v MSYSTEM ]]; then`, similar in Makefile, cygpath conversion, template/conditional code in sources, and so on. But that's a small price to pay, from my perspective, for staying in the same mental model for how to build software.
Exacly. Git supposed to be DVCS not generic DVFS. Choose right tool for right task. I needed generic DVFS to store my docs, so I wrote one. Its easy and quick and does it job :)
As explained, the storage backend in git is pluggable but still not flexible enough.
There has been efforts to store git repos in torrents, and to store got repos on crypto blockchains, but all are big architectural challenges, for example people want everything to be backwards compatible for starters, and some want to be able to partially store some content somewhere else, while still keeping all existing use cases efficient.
There is a huge demand for low-skill labor in other industries. Stuff like plumbing, HVAC, and a ton of other traditionally unsexy jobs that can barely keep enough people in a town to perform these jobs at higher costs than normal.
I agree. I didn't mean to disparage anyone. I have a massive appreciation (and some involvement!) in these trades. The amount of knowledge these guys have about their trade is impressive.
Those jobs don't often pay well until you graduate out of journeyman / apprentice, or are a business owner. They usually require some training and testing ahead of time. They also carry a higher risk of serious injury or death.
you will not land job as plumber or HVAC without piór experience or similar experience. People shun software developers at once im because THEY KNOW that you simply don't fit as typical candidate.
Also: people doesn't want to hire someone who got 'better' education than them... :/
Haha, yeah.. Im using Notepad2 actually, because for LOOONG time, notepad.exe could not display LF files correctly... and Notepad2 has a bit more features, but still.. clean and lean.
Because ML and LLM (Not the fucking AI, it doesnt exist yet) should be used to deal with bulk boring stuff. Filter milions of images to leave interesting. Transform some data (but IM not sure why LLM is interesting here, I can write a script to do so) and so on... Not a creative stuff. This should be left for humans. Because if we take this away, whats left? Low skilled labour at best...
Whats the problem? 1997? They were probably using 10BaseTX network, its 10Mbit...
Using Novel Netware would allow you to trasnfer data at 1MB/s.. quake.exe is < 0.5MB.. so trasnfer will take around 1 sec..
Networking in that era was not a problem. I also don’t know why you’re so steadfast in claiming that builds on local PCs were anything but painfully slow.
It’s also not just a question of local builds for development — people wanted centralized build servers to produce canonical regular builds. Given the choice between a PC and large Sun, DEC, or SGI hardware, the only rational choice was the big iron.
To think that local builds were fast, and that networking was a problem, leads me to question either your memory, whether you were there, or if you simply had an extremely non-representative developer experience in the 90s.
You keep claiming it somehow incurred substantial overhead relative to the potential gains from building on a large server.
Networking was a solved problem by the mid 90s, and moving the game executable and assets across the wire would have taken ~45 seconds on 10BaseT, and ~4 seconds on 100BaseT. Between Samba, NFS, and Netware, supporting DOS clients was trivial.
Large, multi-CPU systems — with PCI, gigabytes of RAM, and fast SCSI disks (often in striped RAID-0 configurations) — were not marginally faster than a desktop PC. The difference was night and day.
Did you actively work with big iron servers and ethernet deployments in the 90s? I ask because your recollection just does not remotely match my experience of that decade. My first job was deploying a campus-wide 10Base-T network and dual ISDN uplink in ~1993; by 1995 I was working as a software engineer at companies shipping for Solaris/IRIX/HP-UX/OpenServer/UnixWare/Digital UNIX/Windows NT/et al (and by the late 90s, Linux and FreeBSD).
That's exactly what you said, and it was incorrect:
> This is exactly the shipping I'm talking about. The gains would be so miniscule (because, again, and incremental compile was never actually slow even on the PC) and the network overhead adds up. Especially back then.
The network overhead was negligible. The gains were enormous.
Visual Assist provided much better completion especially for (then brand-new) C++98 if you used templates, STL etc heavily, but VC had its own completion out of the box that was actually pretty good for plain C code like Quake. AFAIR the "IntelliSense" branding was also in place already.
That link looks like a Ruby-level drawing demo (and I don’t see a public repo or docs behind it).
ruby-libgd is a native, in-process binding to libgd, focused on deterministic rendering and explicit pixel-level primitives, released under the MIT license.
On top of that, I built libgd-gis (also MIT) as a higher-level standard: map rendering, GeoJSON ingestion, layers, tiles, and reproducible output for GIS-style workloads.
ruby-libgd is the low-level graphics engine; libgd-gis is the map renderer built on it.
Yeah, its private stuff.. I added GRX Lib bindings to Ruby so I can use Ruby to do 2D graphics.. Ive been looking for somethink like this but couldnt find anything usefull for me, so I made one..
Thanks for the clarification — that makes sense.
My goal with ruby-libgd / libgd-gis is to provide a public, documented, reusable graphics and map-rendering stack for Ruby.
reply