253
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
this post was submitted on 06 Jan 2024
253 points (93.5% liked)
Asklemmy
44064 readers
757 users here now
A loosely moderated place to ask open-ended questions
Search asklemmy ๐
If your post meets the following criteria, it's welcome here!
- Open-ended question
- Not offensive: at this point, we do not have the bandwidth to moderate overtly political discussions. Assume best intent and be excellent to each other.
- Not regarding using or support for Lemmy: context, see the list of support communities and tools for finding communities below
- Not ad nauseam inducing: please make sure it is a question that would be new to most members
- An actual topic of discussion
Looking for support?
Looking for a community?
- Lemmyverse: community search
- sub.rehab: maps old subreddits to fediverse options, marks official as such
- !lemmy411@lemmy.ca: a community for finding communities
~Icon~ ~by~ ~@Double_A@discuss.tchncs.de~
founded 5 years ago
MODERATORS
That is correct, but a compatibility layer is also not native execution of a binary.
I beg you forgive my pedantic interjection, but ... I posit that the original commenter is incorrect. it is absolutely native execution.
The CPU is fetching and executing the instructions directly from memory, without any (additional) interpretation of code or emulation of missing instructions - Which is, by definition, native execution.
What the compatibility layer "does" is provide a mapping of Windows system calls into the appropriate Linux system calls. Or, in other words, makes it so that calls to functions like
CreateWindowEx()in the Win32 API have a (still native) execution path.The native execution requires you to install WINE, yes, but if we're disqualifying it because "it requires you to install a package", then we also consequently:
~~You're right, you are being pedantic.~~
Edit: Actual response. You took time to type all that out, I should at least say why I disagree.
WINE is a compatibility layer. A translator. It helps a non-native language speaker speak the native language. The whole reason WINE exists is to make a non-native executable execute outside of its native environment. Even if the code is very functionally similar to something like .NET, the function of WINE is to enable non-native code to run as though it were designed for Linux. Downloading WINE doesn't suddenly make those .EXE files be retroactively designed with Linux in mind. It's still not native code.
You're correct in that it is a compatibility layer - And I'm not disagreeing with that. Also to be clear: Not just arguing to argue or trying to start a fight, mind you. I just find this to be an interesting topic of discussion. If you don't find it to be a fun thought experiment, feel free to shoo me away and I'll apologize and leave it alone.
That said, we appear to only be arguing semantics - Specifically around "native" having multiple contextual definitions:
I am using 'native' to mean "the instructions are executed directly by the CPU, rather than through interpretation or emulation" ... which WINE definitely enables for Windows executables running on Linux. It's the reason why Proton/DXVK enables gaming with largely equal (and sometimes faster) performance: There is no interception of execution, there is simply provision of API endpoints. Much like creating a symlink in a directory where something expects it to be: tricking it into thinking the thing(s) it needs are where it expects them to be.
However, you are using 'native' to mean "within the environment intended by the developer", and if that's the agreed definition then you're correct.
That's where this becomes an interesting thought experiment to me. It hits me as a very subjective definition for "native", since "within the intended environment" could mean a lot of things.
Does that make sense? I hear a statement like that and I find myself wondering Which layer along the chain makes it "native"? - I find myself curious at what point the definition changes, in a "Ship of Theseus" kind of way.
It seems to me that if we agree that the above means "running in WINE is not native", then we must also agree that "anything written running for .NET (or any other framework, really) is not native", since .NET apps are written for the .NET framework (Which is not only officially available for Windows, mind you) and often don't include anything truly Windows-specific. Ultimately, both are providing natively-executed instructions that just translate API calls to the appropriate system calls under the hood.
I hope that does a better job of characterizing what I meant.
You clearly know more about this than I do, and you've thought a lot about it. Your points deserve a better response than I can give at this time, but I wanted to acknowledge that at least. I also wanted to say you aren't pedantic and I'm sorry I said that. You spent time and thought on making a good conversation and I wish I had been more engaging with that instead of trying to be correct. Thank you for still conversing instead of arguing even after I was less than perfect of a conversation partner. I hope in the future I see more of your comments. Have a really nice day.
I appreciate your acknowledgement - and I commend the humility it takes to write a comment like this! No hard feelings at all, and I hope things are pleasant for you as well.
It's folks like you and interactions like this that make Lemmy a platform worth engaging on.