Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

I fixed Windows native development

marler8997.github.io

Post reply on HN
Print view View original

131–140 of 406 posts

Re: I fixed Windows native development

#131

Post by fao_ »

crote wrote: post #128
calvinmorrison wrote: post #115

Earlier quoted context omitted.

> Toolchains on linux are not clear from dependency hell either - ever install an npm package. That's where I stopped. Toolchains on linux distributions with adults running packaging are just fine. Toolchains for $hotlanguage where the project leaders insist on reinventing the packaging game, are not fine. I once again state these languages need to give up the NIH and pay someone mature and responsible to maintain pa…

The counterpoint of this is Linux distros trying to resolve all global dependencies into a one-size-fits-nothing solution - with every package having several dozen patches trying to make a brand-new application release work with a decade-old release of libfoobar. They are trying to fit a square peg into a round hole and act surprised when it doesn't fit. And when it inevitably leads to all kinds of weird issues the p…

> The counterpoint of this is Linux distros trying to resolve all global dependencies into a one-size-fits-nothing solution - with every package having several dozen patches trying to make a brand-new application release work with a decade-old release of libfoobar. They are trying to fit a square peg into a round hole and act surprised when it doesn't fit.

This is only the case for debian and derivatives, lol. Rolling-release distributions do not have this problem. This is why most of the new distributions coming out are arch linux based.

Re: I fixed Windows native development

#132

Post by reactordev »

jezek2 wrote: post #84
okanat wrote: post #73

Earlier quoted context omitted.

You can use Mingw-w64 UCRT or CLANG environments that come with MSYS2. Compared to older Mingw64 environments those link with the latest UCRT so you get almost the same style executable as Visual Studio. The only difference for C is that it uses Mingw exception handling and global initialization code, and it uses Itanium ABI for C++.

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.

Re: I fixed Windows native development

#133

Post by p_ing »

nanoxide wrote: post #89
tgtweak wrote: post #64

Toolchains on linux are not clear from dependency hell either - ever install an npm package that needs cmake underneath? glibc dependencies that can't be resolved because you need two different versions simultaneously in the same build somehow... python in another realm here as well. That shiny c++ project that needs a bleeding edge boost version that is about 6 months away from being included in your package manager…

When was the last time you actually used. NET? Because that's absolutely not how it is. The. NET runtime is shipped by default with Windows and updated via WU. Let alone that you're talking about .NET Framework which has been outdated for years.

.NET runtime is not shipped with Windows, but once installed can be updated by WU.

Only the latest .NET Framework 4.8 is shipped with Windows at this point.

Re: I fixed Windows native development

#134

Post by amenhotep »

esseph wrote: post #59
its_notjack wrote: post #34

Is this post AI-written? The repeated lists with highlighted key points, the "it's not just [x], but [y]" and "no [a] just [b]" scream LLM to me. It would be good to know how much of this post and this project was human-built.

> Is this post AI-written? What if it was? What if it wasn't? What if you never find out definitely? Do you wonder that about all content? If so, doesn't that get exhausting?

Yeah, it does. Congratulations, you figured out why the future is going to be fucking awful.

Re: I fixed Windows native development

#135

Post by tomkarho »

tgtweak wrote: post #64

Toolchains on linux are not clear from dependency hell either - ever install an npm package that needs cmake underneath? glibc dependencies that can't be resolved because you need two different versions simultaneously in the same build somehow... python in another realm here as well. That shiny c++ project that needs a bleeding edge boost version that is about 6 months away from being included in your package manager…

.NET does have flags to include the necessary dependencies with the executable these days so you can just run the .exe and don't need to install .net on the host machine. Granted that does increase the size of the app (not to mention adding shitton of dll's if you don't build as single executable) but this at least is a solved problem.

Re: I fixed Windows native development

#136

Post by marcosdumay »

glimshe wrote: post #9
dgxyz wrote: post #8

Earlier quoted context omitted.

Yes. Any user interface toolkit that isn't at least 10 years old should be ignored on windows unless you want to rewrite everything one day.

I wonder if people still use WinForms, MFC and WPF...

I'd guess WinForms is still the most popular widget library in Windows.

Re: I fixed Windows native development

#137

Post by sitzkrieg »

jezek2 wrote: post #75

I wish open source projects would support MingW or at least not actively blocking it's usage. It's a good compiler that provides an excellent compatibility without the need of any extra runtime DLLs. I don't understand how open source projects can insist on requiring a proprietary compiler.

if you want to link msvc built libraries (that are external/you dont have source), mingw may not be an option. for an example you can get steamworks sdk to build with mingw but it will crash at runtime

Re: I fixed Windows native development

#138

Post by a-dub »

it's been 14 years since i've used msvc for anything real. iirc the philosophy back then was yearly versioned releases with rolling intermediate updates.

this seems to go down the road towards attempts at determinsticish builds which i think is probably a bad idea since the whole ecosystem is built on rolling updates and a partial move towards pinning dependencies (using bespoke tools) could get complicated.

Re: I fixed Windows native development

#140

Post by okanat »

reactordev wrote: post #117
michaelsbradley wrote: post #109

Earlier quoted context omitted.

Aren’t you thinking of Cygwin, or the MSYS2 shell (dev tooling)? The Windows-native software you build with MSYS2 can be shipped to and run by users that don’t have anything of MSYS2 installed.

He must be thinking of Cygwin as half of this is installed when you install git ;) Git Bash, etc…

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.

Post reply on HN