The Lounge is rated Safe For Work. If you're about to post something inappropriate for a shared office environment, then don't post it. No ads, no abuse, and no programming questions. Trolling, (political, climate, religious or whatever) will result in your account being removed.
Or equally reasonably,
the developer does not have access to the OS that you are running.
Do you have access to:
Linux x86-64,i386,arm32,arm64 rpm format
Linux x86-64,i386,arm32,arm64 deb format
Then there's all the minor players like pacman on Arch Linux, AmigaDOS, (Net,Free,Open)BSD, Haiku etc.
Chances are that if you provide a useful tool in source code, somebody will figure out how to compile it on their system and, hopefully, feed the changes back to you, or at least make them available to others
it was common on linux because of different platforms, c/c++ compiles down to native machine code and linux (more so unix) runs on many different hardware from PDP to IBM. Even on the same architecture a lot had to be handled before compiling such as byte order, sizeof's (32/64 bit ints)....
the unix way was also often "here's my answer, feel free to take it as is, or improve it for yourself/purpose.
a lesser (later) reason was the "what's really inside" worries - compiled to native even decompiling/disassembling didn't tell you much (or being assembly told you way too much in painfully simple detail... MOV 1 A, CMP A B... 325,000 lines, is there a trojan in there somewhere?).
when windows came out compilers were both expensive and uncommon but it was only one architecture (ms introduced it's own hacks for 32 bit code on 64 bit machines) so giving compiled code was fine as long as you trusted the author/download site (and enough others had tried it and didn't get ransomwared.)
A few unix folks jumped into some windows dev, their habits often didn't change (i.e. provide the source: use as is or mod it yourself.)
after many otherwise intelligent sounding suggestions that achieved nothing the nice folks at Technet said the only solution was to low level format my hard disk then reinstall my signature. Sadly, this still didn't fix the issue!
A remnant from ye olden days!
Building software back then sounds like a real PITA...
I really wish those Unix devs got with the times and gave me an installer though
I'm really not going to download the C/C++ tooling just so I can try out this one tool.
To be fair, I'm not a C/C++ developer, which is who this tool is for.
I just need it to test some functionality of another tool, but I'm just going to take their word for it
Nowadays, there are lots of naive peope cheering "Containers! Docker! Hallelujah!", believing that once you have put the stuff into a container, it is "build once, run anywhere!" Sure...! The interface between host and the running container is, at the functional level, reasonably simple; it is realistic to implment it on "any" architecture. But inbetween the host/container interactions, the container is on its own - together with the CPU, of course.
When Apple jumped from 68K to x86, they developed an emulator for running 68K code on the x86 that was surprisingly efficient. There is nothing like that in the Docker container. If the machine code inside the container is x86, the CPU better be x86, too! "Run anywhere, provided that you are on an x86" is sort of "You can have the T-Ford in any color you want, as long as you want it it black". Lots of Docker affectionados haven't realized that yet.
Obviously, the host may - outside the container - provide an emulated CPU by having, say, a PPC cpu interpret in software every x86 instruction code. You could hardly describe that as "lightweight" virtualization! And for it to be universally "run anywhere", every Docker host would have to be able to emulate any instruction set that might be found within a container.
I wonder if MS is working on containerization where the code inside consists of dotNet assemblies, compiled on-the-fly to the native code of the host. That could be (part of) a solution for truly build once, run everywhere. (The CLR sort of provides (parts of) this, but without the container protection.) I think that Docker containers will live for many years, but it is certainly not the last word in container technology. My guess is that the container/host interface in future techologies may include some JIT code generating, so that the container at startup (/JIT) deliver something like an assembly to host and get the native binary code back for execution in the containerized enviromment. That will probably be in a container framework different from today's Docker, though.
The real reason is that everyone and his kid brother have taken Linux, and bent/folded/stapled it so that it is incompatible with any other version (including those compiled for the same hardware). In other works, there is no agreed ABI which guarantees that a shared library compiled for x64 on one system will run on another x64 system.
In this jungle, the only way to ensure that code will work is to compile it locally. If the code compiles (sometimes - this is a big if...), it will probably work on your machine. Otherwise, you're SOL.
Especially the DataGridView was a horror to work with
It still is...
"When you are dead, you won't even know that you are dead. It's a pain only felt by others; same thing when you are stupid."
Ignorant - An individual without knowledge, but is willing to learn. Stupid - An individual without knowledge and is incapable of learning. Idiot - An individual without knowledge and allows social media to do the thinking for them.
Let me clarify my comment: imho, in this later stage of personal computing where rich user interfaces are the norm, the Catch-22 of any attempt at having a multi-OS dev solution is that really rich, complex, controls ... not buttons, checkboxes, monofont textboxes ... probably need to access OS dependent facilities under-the-hood for platform-centric look-and-feel, for rendering speed and fidelity.
Sander Rossel wrote:
I remember the WinForms controls were not even half-decent
imho, for their time, they were useful, and free, and their limitations drove a thriving 3rd, party control industry, as well as many wonderful CP articles.
cheers, the old fossil, Bill
«One day it will have to be officially admitted that what we have christened reality is an even greater illusion than the world of dreams.» Salvador Dali
Safe and protective in that so long as you don't venture out all the parts (at least in theory) work together and consistently.
Perhaps modify that to .NET on Windows - or may .NET on WindowsN. For, you see, code I wrote for XP didn't quite work on 7 - but I got it to work. But them more changes came about - Win7 on VMWare started to stop working.
If one stays completely in a single world it becomes, as Candid was taught by his mentor, Pangloss, 'since this is the only possible world then it is the best of all possible worlds".