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

381–390 of 406 posts

Re: I fixed Windows native development

#381

Post by thinkyfish »

torginus wrote: post #43
jasode wrote: post #33

Earlier quoted context omitted.

>It starts by not looking into Windows through UNIX developer glasses. People don't need any UNIX biases to just want multiple versions of MSVS to work the way Microsoft advertises. For example, with every new version of Visual Studio, Microsoft always says you can install it side-by-side with an older version. But every time, the new version of VS has a bug in the install somewhere that changes something that breaks…

Note that this also doesn't work on Linux - your system's package manager probably has no idea how to install and handle having multiple versions of packages and headers. That's why docker build environments are a thing - even on Windows. Build scripts are complex, and even though I'm pretty sure VS offers pretty good support for having multiple SDK versions at the same time (that I've used), it only takes a single s…

Guix and Nix can do that. They were built from the ground up to be able to have multiple, simultaneous versions of everything installed in separate store, and you can request on a per shell basis what you want in your environment.

Re: I fixed Windows native development

#382

Post by iririririr »

pjmlp wrote: post #234
iririririr wrote: post #107

Earlier quoted context omitted.

I last developed for windows in the late 90s. I came back around 2017*, expecting the same nice experience I had with VB3 to 6. What a punch in the face it was... I honestly cannot fathom anyone developing natively for windows (or even OSX) at this day and age. Anything will be a webapp or a rust+egui multi-plataform developed on linux, or nothing. It's already enough the amount of self-hate required for android/ios.…

And yet without Proton there are no Linux games.

what that have to do with anything?

does proton make current vb development as straight forward as it was on vb6?

Re: I fixed Windows native development

#383

Post by p_ing »

ryandrake wrote: post #333
p_ing wrote: post #240

Earlier quoted context omitted.

Hey I have a PC running 98SE ;-) I feel for those who have to support an OS no longer supported by the vendor. That's a tough position to be in, not only if a customer comes across a bug that is due to the OS, but it keeps you from advancing your desktop application forward.

You can always have legacy builds for older systems and use shiny new features inside conditional compilation blocks. Or check at runtime and let newer operating systems use the new features. Yes it takes care and a little more testing to keep supporting older operating systems but your users will love you for it. I’m always kind of sad when a developer says to a customer “your OS is too old. We are dropping you on t…

Sure, you can take on that technical debt! ;-)

Re: I fixed Windows native development

#384

Post by doctorleff »

In the 1990s, I taught GUI programming with the following two books (not necessarily those editions). Is this post the tool chain to do that program creation from the command line for these? Now that I am retired from a third of a century as a computer science faculty member, I would like to resurrect those notes for a comprehensive learning module on GUI programming. (At the turn of the century, my University had me teach GUI programming with Java Swing.) In my opinion, all are wonderful as is old-fashioned x-Windows GUI programming and Visual Basic form development, both of which I briefly introduced to my students.

Programming Windows with MFC, Second Edition Subsequent Edition by Jeff Prosise (Author)

Programming Windows®, Fifth Edition (Microsoft Programming Series) Subsequent Edition by Charles Petzold (Author)

Re: I fixed Windows native development

#385

Post by torginus »

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 Framework is a Windows system component, but it's been deprecated and Microsoft is moving away from it. The modern .NET ships as either a downloadable runtime/SDK, or can be bundled with your application, meaning your app has no dependencies.

Re: I fixed Windows native development

#387

Post by pjmlp »

iririririr wrote: post #382
pjmlp wrote: post #234

Earlier quoted context omitted.

And yet without Proton there are no Linux games.

what that have to do with anything? does proton make current vb development as straight forward as it was on vb6?

Proton allows Linux users to enjoy Windows games, developed on Windows, with Visual Studio and DirectX.

Re: I fixed Windows native development

#388

Post by forrestthewoods »

troad wrote: post #379
forrestthewoods wrote: post #341

Earlier quoted context omitted.

I've been shipping Windows software for 20+ years. Not one project I have ever worked on was based on MinGW. It's a gross hack that is ABI incompatible with the predominate ecosystem. In the year 2026 there is no reason to use MinGW. Just use Clang and target MSVC ABI. Cross-compiling Linux->Windows is very easy. Cross-compiling Windows->Linux is 1000x harder because Linux userspace is a clusterfuck of terrible desig…

>> It's a gross hack * taps on the name of this site * If I'm writing some cross-platform bit of software, my interest in supporting Windows is naturally in producing binaries that run on Windows . Why on earth should I give a flying toss how "almost all Windows software is developed", or which kinds of ABIs are BillG-kissed and approved? Good god. Talk about fetishising process over outcome.

I just eyerolled so hard I gave myself a migraine.

If your focus is on outcome that I promise and assure you that using MinGW will make producing a positive outcome significantly harder and more frustrating.

With modern Clang there really isn’t a justifiable reason to use MinGW.

Re: I fixed Windows native development

#389

Post by eqvinox »

xg15 wrote: post #370
eqvinox wrote: post #348

Earlier quoted context omitted.

> https://sourceware.org/bugzilla/show_bug.cgi?id=32653 dlopen and dlmopen no longer make the stack executable if a shared library requires it I'm not counting intentional breakage to improve system security. I'm not even sure I'd call it an ABI breakage; by a wide definition I guess it is a "change in glibc that makes things not work anymore". You also can't execute a.out binaries anymore, eh. And I don't think I wo…

You can have one of "they're so serious about forward and backward compat you should remove version pins because things won't ever break" and "well, I'm not counting intentional breaks" but not both.

Why? Is it not normal to have a first priority and a second priority? Does it not make sense for security to come before other things?

Re: I fixed Windows native development

#390

Post by xg15 »

eqvinox wrote: post #389
xg15 wrote: post #370

Earlier quoted context omitted.

You can have one of "they're so serious about forward and backward compat you should remove version pins because things won't ever break" and "well, I'm not counting intentional breaks" but not both.

Why? Is it not normal to have a first priority and a second priority? Does it not make sense for security to come before other things?

I don't know much about glibc's specifics, but in general: Security comes before a lot of things but not before accidental breakage. If you say "our compat guarantees are so strong you shouldn't keep track of versions at all", I expect this to mean that APIs and ABIs will never change, or at least not without a massive awareness campaign and transition plan being announced before - because such a breakage would take out my project or might even introduce new vulnerabilities.

A security update that also does breaking changes is sort of the worst case, because dependents are essentially damned if they apply it and damned if they don't. They can't always be avoided if an API is so insecure it's beyond repair - but then dependents will have to update in their own time because they will also have to fix their own implementations. So this would be an argument for version pins in that case.

Post reply on HN