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

211–220 of 406 posts

Re: I fixed Windows native development

#211

Post by moogly »

giancarlostoro wrote: post #77
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…

I went from POP OS (Ubuntu) to EndeavourOS (Arch) Linux because some random software with an appimage or whatever refused to run with Ubuntus “latest” GLIBC and it ticked me off, I just want to run more modern tooling, havent had any software I couldnt just run on Arch, going on over a year now.

Indeed. As late as 2 hours ago I had to change the way I build a private Tauri 2.0 app (bundled as .AppImage) because it wouldn't work on latest Kubuntu, but worked on Fedora and EndeavourOS. So now I have to build it on Ubuntu 22.04 via Docker. Fun fun.

Had fewer issues on EndeavourOS (Arch) compared to Fedora overall though... I will stay on Arch from now on.

Re: I fixed Windows native development

#212

Post by jjkaczor »

jjkaczor wrote: post #47

While this is great - Visual Studio installer has a set of "command-line parameters" for unattended installs. You can then build a script/documentation that isolates your specific requirements and workloads: https://learn.microsoft.com/en-us/visualstudio/install/use-c... Had to do this back in 2018, because I worked with a client with no direct internet access on it's DEV/build machines (and even when there was conne…

(ugh - "high-latency" connections...)

Re: I fixed Windows native development

#213

Post by KTibow »

jjkaczor wrote: post #47

While this is great - Visual Studio installer has a set of "command-line parameters" for unattended installs. You can then build a script/documentation that isolates your specific requirements and workloads: https://learn.microsoft.com/en-us/visualstudio/install/use-c... Had to do this back in 2018, because I worked with a client with no direct internet access on it's DEV/build machines (and even when there was conne…

I tried this once. It downloaded way more stuff than needed and still required admin to actually install.

Re: I fixed Windows native development

#214

Post by itishappy »

dataflow wrote: post #129
itishappy wrote: post #102

Earlier quoted context omitted.

Since roughly September 2022 with the release of WSL 0.67.6!

Have you actually attempted to use it recently? Are you familiar with the WSL1 bugs that surface when running random Linux distros? (To be clear, I haven't tried this with Nix, but I have with other distros.)

Fair question! Nope. I'm not endorsing it, and certainly don't know (or even suspect) it would solve this issue. I just recently installed NixOS and was surprised to see Windows mentioned on the downloads page, so looked into it a bit. Maybe soon.

Re: I fixed Windows native development

#215

Post by cmovq »

dimgl wrote: post #121

> The build.bat above isn’t just a helper script; it’s a declaration of independence from the Visual Studio Installer. I am so fed up with this! Please if you're writing an article using LLMs stop writing like this!

I never understood this sentence structure, it adds zero information, it always goes like:

“This isn’t just [what the thing literally is]; it’s [hyperbole on what the thing isn’t].”

Re: I fixed Windows native development

#216

Post by the__alchemist »

Pay08 wrote: post #196
the__alchemist wrote: post #105

Earlier quoted context omitted.

This is one of the things that tilts me about C and C++ that has nothing to do with mem safety: The compile/build UX is high friction. It's a mess for embedded (No GPOS) too in comparison to rust + probe-rs.

That hasn't been my experience at all. Cross-compiling anything on Rust was an unimaginable pain (3 years or so ago). While GCCs approach of having different binaries with different targets does have its issues, cross compiling just works.

Ah sorry. I should clarify. Not referring to specifically cross compiling; just general compiling. In rust weather PC or embedded, I run Cargo run. For C or C++, it's who knows. A provincial set of steps for each project, error messages, makes me get frustrated. I keep a set of notes for each one I touch to supplement the project's own docs. I am maybe too dumb or inexperienced in some cases, but I am having a hard time understanding why someone would design that as the UX.

I want to focus on the project itself; not jump through hoops in the build process. It feels hostile.

For cross compiling to ARM from a PC in rust in particular, you do one CLI cmd to add the target. Then cargo run, and it compiles, flashes, with debug output.

These are from anecdotes. I am probably doing something wrong, but it is my experience so far.

Re: I fixed Windows native development

#217

Post by tgtweak »

p_ing wrote: post #204
tgtweak wrote: post #195

Earlier quoted context omitted.

The issue is in supporting older windows versions - which sadly is still a reality for most large-scale app developers.

https://github.com/dotnet/core/blob/main/release-notes/10.0/... .NET 10 supports a Windows 10 build from 10 years ago.

Yes and in the wild believe it or not you'll find windows 7 and windows 8.

We had just deprecated support for XP in 2020 - this was for a relatively large app publisher ~10M daily active users on windows. The installer was a c++ stub which checked the system's installed .NET versions and manually wrote the app.config before starting the .net wrapper (or tried to install portable .NET framework installer if it wasn't found at all).

The app supported .NET 3.5* (2.0 base) and 4 originally, and the issue was there was a ".NET Framework Client Profile" install on as surprising amount of windows PCs out there, and that version was incompatible with the app. If you just have a naked .NET exe, when you launch it (without an app.config in the current folder) the CLR will decide which version to run your app in - usually the "highest" version if several are detected... which in this case would start the app in the lightweight version and error out. Also, in the app.config file you can't tell it to avoid certain versions you basically just say "use 4 then 2" and you're up to the mercy of the CLR to decide which environment it starts you in.

This obviated overrides in a static/native c++ stub that did some more intelligent verifications first before creating a tailored app.config and starting the .net app.

Re: I fixed Windows native development

#218

Post by jjkaczor »

KTibow wrote: post #213
jjkaczor wrote: post #47

While this is great - Visual Studio installer has a set of "command-line parameters" for unattended installs. You can then build a script/documentation that isolates your specific requirements and workloads: https://learn.microsoft.com/en-us/visualstudio/install/use-c... Had to do this back in 2018, because I worked with a client with no direct internet access on it's DEV/build machines (and even when there was conne…

I tried this once. It downloaded way more stuff than needed and still required admin to actually install.

Well - "run as admin" wasn't a problem for that scenario - as I was also configuring the various servers.

(And - it is better on a shared-machine to have everything installed "machine-wide" rather than "per-user", same as PowerShell modules - had another client recently who had a small "C:" drive provisioned on their primary geo-fenced VM used for their "cloud admin" team and every single user was gobbling too much space with a multitude of "user-profile" specific PowerShell modules...)

But - yes, even with a highly trimmed workload it resulted in a 80gb+ offline installer. ... and as a server-admin, I also had physical data-center access to load that installer package directly onto the VM host server via external drive.

Re: I fixed Windows native development

#219

Post by IshKebab »

LtWorf wrote: post #161
IshKebab wrote: post #113

Earlier quoted context omitted.

> python in another realm here as well uv has more of less solved this (thank god). Night and day difference from Pip (or any of the other attempts to fix it honestly). At this point they should just deprecate Pip.

Ah yes let's all depend on some startup that will surely change the license at some point.

Very clearly a better option than continuing to use Pip. Even if they do change the license in a few years I will definitely take several years of not being shat on by Pip over the comparatively minor inconvenience of having to switch to an open fork of uv when they rug-pull. If they ever do.

Continuing to use Pip because Astral might stop maintaining uv in future is stupidly masochistic.

Re: I fixed Windows native development

#220

Post by Pay08 »

the__alchemist wrote: post #216
Pay08 wrote: post #196

Earlier quoted context omitted.

That hasn't been my experience at all. Cross-compiling anything on Rust was an unimaginable pain (3 years or so ago). While GCCs approach of having different binaries with different targets does have its issues, cross compiling just works.

Ah sorry. I should clarify. Not referring to specifically cross compiling; just general compiling. In rust weather PC or embedded, I run Cargo run. For C or C++, it's who knows. A provincial set of steps for each project, error messages, makes me get frustrated. I keep a set of notes for each one I touch to supplement the project's own docs. I am maybe too dumb or inexperienced in some cases, but I am having a hard t…

That sounds like you don't have a build system for C/C++.
Post reply on HN