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

Cross-compiling binaries for Windows is easier than building natively

gist.github.com

Post reply on HN
Print view View original

181–190 of 349 posts

Re: Cross-compiling binaries for Windows is easier than building natively

#181

Post by MereInterest »

nemothekid wrote: post #170
Pathogen-David wrote: post #56

Earlier quoted context omitted.

NTFS has supported them for ages. The main issue is that they're locked behind elevated permissions or having developer mode enabled (as of Windows 10.) 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.

> 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); from there you put in a large path and then you get your RCE.

That would be for removing the 260 character limit, not for enabling of symlinks.

Re: Cross-compiling binaries for Windows is easier than building natively

#182

Post by kretaceous »

I mostly agree on the VSCode part. They should put it up front in the README, homepage and maybe a info modal/badge whenever a user installs said extension.

But genuinely asking, how else would you 'label' VSCode?

"A free and open-source code editor with some optional components that are proprietary"?

Re: Cross-compiling binaries for Windows is easier than building natively

#183

Post by Arnavion »

criddell wrote: post #154
Arnavion wrote: post #118

Earlier quoted context omitted.

If you want to build binaries for a distro, build in that distro. If that distro has a Docker image, it's as simple as: docker run -v "$PWD:/src" olddistro:version /src/build.sh $dayjob supports distros as old as CentOS 7 and as new as Ubuntu 22.04 this way. 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…

CentOS 7 is from 2014. That isn’t very old.

It has a few old things unique to it in our support matrix. It's the only distro with openssl 1.0 so a bunch of API and related things are different. It's also the only distro where systemd socket activation doesn't work if your service has more than one socket, because its version of systemd predates the LISTEN_FDNAMES env var.

Also, it is old enough that it's going out of LTS soon.

Re: Cross-compiling binaries for Windows is easier than building natively

#184

Post by MereInterest »

Pathogen-David wrote: post #56
colejohnson66 wrote: post #4

Earlier quoted context omitted.

I agree that Windows could do more to support the developers on other platforms. Symlinks just seem like a petty thing to complain about IMHO. Didn’t realize how common they were though. NTFS does support them, however. Is Git just not supporting them properly?

NTFS has supported them for ages. The main issue is that they're locked behind elevated permissions or having developer mode enabled (as of Windows 10.) 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.

I've looked before, and have never found a definitive answer from Microsoft. I've heard some speculation that it the nebulous security issues would be from a program that checks the permissions of a symlink's target, then opens the symlink. An attacker could then modify the symlink after the permission check but before the file is opened, escalating access by pointing to a restricted file.

Re: Cross-compiling binaries for Windows is easier than building natively

#185

Post by charcircuit »

ripley12 wrote: post #171
charcircuit wrote: post #169

Earlier quoted context omitted.

So it's the public word of someone from the .NET team versus your unnamed sources. It sounds like there was a communication issue as from the blog post the reason given behind removing it wasn't to drive sales of Visual Studio. It sounds like if their team had more resources it wouldn't have been cut which invalidates the point of them using it to promote VS.

That post by Scott Hunter was a way to save face after Liuson backed down. It is absolutely not truthful about the original reason for removing dotnet watch, and was widely criticized as such at the time. Please trust me on this; the whole dotnet watch drama consumed my life for a good week when it happened. If you want a source from the .NET team, Miguel de Icaza has since quit Microsoft and is able to be more open…

>That post by Scott Hunter was a way to save face after Liuson backed down

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.

Re: Cross-compiling binaries for Windows is easier than building natively

#186

Post by sumy23 »

downut wrote: post #164
sumy23 wrote: post #98

Earlier quoted context omitted.

I live in a small apartment with my partner who also works from home. We don’t have enough space to dedicate to two desks. We also travel a lot, so I need to be able to take my work with me.

It is a weird thing to me that a minimal impact lifestyle[0] requires a very constrained and expensive computer ecosystem to facilitate unrealized happiness. [0] ...but with frequent travel?

We have a small, nearly off the grid cottage (septic, water from the lake, no roads, etc.). It has an internet connection via a Ubiquiti antenna. Not enough room for two desks there either.

Re: Cross-compiling binaries for Windows is easier than building natively

#187

Post by dwattttt »

adzm wrote: post #157
josephcsible wrote: post #134

Earlier quoted context omitted.

> I'm a native Win32 developer, have been one for a few decades, and know quite a few others still using MSVC6 Doesn't that tie you to a really old C runtime, and aren't security holes often found in the C runtime?

It links dynamically to msvcrt.dll which is updated as part of the os. I believe it still gets updates as long as it doesn't break the ABI. Modern vc++ links with the universal CRT which is an independently updated msvcrt distribution.

msvcrt.lib includes things other than direct imports to msvcrt.dll; bugs in that code are going to be linked into your binary at compile time.

Re: Cross-compiling binaries for Windows is easier than building natively

#188

Post by cube00 »

userbinator wrote: post #72

Only if you want to be trendchasing rather than letting backwards compatibility take care of itself... 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 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 ~…

It's depressing how fast and responsive MSVC6 runs on today's hardware compared with the current version of Visual Studio.

Re: Cross-compiling binaries for Windows is easier than building natively

#189

Post by a-dub »

labrador wrote: post #18

This what is called in Cognitive Behavioral Therapy "All or Nothing Thinking." Microsoft is a for-profit company. It is pro open-source when it helps them and closed source also when it helps them. I like the new Microsoft which has open sourced a lot of stuff. It's way better than the old closed source regime.

yeah the acceptance of oss is cool but they still ship a lot of weird software and technology... which is fine assuming you can avoid it... but sometimes you can't and then it becomes torturous.
Post reply on HN