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

291–300 of 349 posts

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

#291

Post by wdb »

fyrn- wrote: post #126
wdb wrote: post #116

I agree that symlinks cause more trouble then is needed on any platform. Sadly, only Node really likes to use them to optimise the store of packages Personally, I don't have major issues compiling things on Windows for other platforms (macOs, Win32, Android, Linux). Only awkward thing is designing UIs

I don't think that's what they sre saying, I think they sre saying it's stupid Microsoft requires hoops for such a basic feature, hence "Fix Windows" being option 1

I don't agree that symlinks are a basic feature. It's a source of a lot of pain for me on my Mac

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

#292

Post by pjmlp »

indymike wrote: post #276
pjmlp wrote: post #252

Earlier quoted context omitted.

Cloud workloads mean UNIX has effectively won the server room for classical deployments, however UNIX !== Developer. There are plenty of other workloads and platforms to target. Desktop, mobile devices, IoT, medical, game consoles, infotainment, unikernel, serverless....

Mobile is almost all IOS and Android... and mostly but not all devs use Macs due to xcode. The only places that Windows seems to persist are developer markets where tooling choices are limited to Windows (games, medical, embedded) or corporate standards dictate tooling.

> Mobile is almost all IOS and Android... and mostly but not all devs use Macs due to xcode.

Indeed and trying to use UNIX for mobile apps won't bring you far.

> The only places that Windows seems to persist are developer markets where tooling choices are limited to Windows (games, medical, embedded) or corporate standards dictate tooling.

The remaining 99% of the market where UNIX GUIs don't matter.

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

#293

Post by i45_n5 »

5e92cb50239222b wrote: post #231
cube00 wrote: post #188

Earlier quoted context omitted.

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

It started after they ported UI to WPF. Compare VS2008 and VS2010 if you have the time. I remember using both on a cheap laptop when VS2010 first came out, and was simply incomparable.

Yes, absolutely true. vs08 was their last fast ide.

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

#294

Post by pjmlp »

forgotpwd16 wrote: post #264
pjmlp wrote: post #38

Earlier quoted context omitted.

https://docs.microsoft.com/en-us/windows-server/administrati...

Pointing to this page is meaningless. `mklink /d` only works on NTFS but errors out ("The device does not support symbolic links.") on exFAT. GP acknowledges NTFS has symlinks and remarks that exFAT doesn't.

NTFS is the only filesystem that matters for Windows developers.

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

#296

Post by Tempest1981 »

MereInterest wrote: post #176
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 ~…

My issue with the 260 character limit is that it can easily be reached through normal usage, and can lead to some really strange behavior. * File cannot be moved into a subfolder. * Folder can be renamed, after which a file contained within it is inaccessible. * File on a network drive may be accessible by some users, but not others. For example, one user may access the drive with the longer network name, while anoth…

Exactly. I believe NTFS has supported 65535-char paths since, forever? But last I checked, even simple apps like Win10 Notepad will fail to open them.

What is the point of the registry/gpedit setting to enable long paths system-wide -- when so much of Windows doesn't support it? File Explorer is really showing its age.

Has any of this improved in Win11?

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

#297

Post by Shorel »

themerone wrote: post #206
anotherevan wrote: post #179

Earlier quoted context omitted.

NSIS (Nullsoft Scriptable Install System)[1] can be compiled[2] for Linux if that's any help. I use that to prepare the install .exe package for a Java based program for one of my clients. [1] https://nsis.sourceforge.io/Main_Page [2] E.g.: https://aur.archlinux.org/packages/nsis / https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=nsis

NSIS is not a substitute. It's good for shipping to home users, but msi installers are essential for enterprise software distribution.

You can use .exe installers as well.

It is only a bit more work

https://activedirectorypro.com/deploy-software-exe-using-gro...

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

#298

Post by Shorel »

codedokode wrote: post #217

The post mentions CRLF line end syntax, I don't understand why anyone should bother with it. Use \n only, it works everywhere including Windows. Any modern IDE can handle Unix line endings. The same about file paths, use forward slash (/) everywhere and don't waste your time supporting DOS era standards. I think the core.autocrlf option in Git is more harmful than useful (for example, it can change file hashes and br…

> I think the core.autocrlf option in Git is more harmful than useful

Nowadays, I am willing to agree with you. It breaks more things than fixes them.

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

#300

Post by rkeene2 »

Spivak wrote: post #108
andrewmcwatters wrote: post #97

Earlier quoted context omitted.

Anyone who talks nonchalantly about glibc hasn't had their time eaten up by glibc.

Like it’s absolutely a nightmare but you can eliminate a lot of problems by building on an ancient version of RHEL.

You can also just cross-compile targeting whatever you want, including RHEL.

I wrote a tool [0] which will take any system and create a cross-compiler toolchain for it, this is what I use to compile for Linux, HP-UX, Solaris, BSD, etc on Linux.

[0] https://build-cc.rkeene.org/

Post reply on HN