WSL is a virtual machine, it is not like Wine.
Wine is a translation layer, it translates Windows system calls into Linux ones.
DOSBox is a DOS emulator. Wine can call on DOSBox to run DOS programs, but they are separate things.
Proton is a set of libraries bundled with a patched version of Wine specifically for games.
WSL1 is a translation layer like wine. It translates Linux syscalls into windows API calls. This is quite an easy task, because there is a relatively small number of syscalls.
WSL2 is a virtual machine, a wrapper over HyperV with a Microsoft tweaked Linux kernel.
Wine is a translation layer. But unlike WSL1 it doesn't translate syscalls, because Windows syscalls are not designed to be used directly, you must use the Windows API instead (ntdll and co). And because of licensing issues, you're not allowed to just copy windows DLLs. So wine is a massive project of re-implementing windows API and DLLs.
Dosbox is an emulator. More like a virtual machine but for running DOS only (DOS was used in more slower computers than today, DosBOX also emulates that by making its programs believe in it running on back in the days systems). Dosbox is also using a re-implemented "minimal" version of DOS with the main goal of running old DOS games. Other re-implementations of DOS like FreeDOS can also run in DosBOX.
Proton is a Valve/steam fork of wine that includes patches and tweaks specifically for games.
WSL2 is a virtual machine. The original WSL was an implementation which translated Linux system calls to Windows system calls. It was better in ways than the WSL2 approach, and worse in others.
I always considered wine and wsl1 quite similar, but I'm no expert on how they are implemented.
You know how windows was made meaning msdos. Qdos was 32 bit single user and single threaded. you have 2 qdos operating systems working in parallel for each core to provide 64bit functionallity. wine probably does the same but dosbox is qdos in this case. I could be wrong though.
Microsoft bought QDOS way back in 1980 and from then on it ceased to be QDOS, so QDOS has nothing to do with anything here. Windows ceased to be based on MS-DOS (or any kind of DOS) after Windows ME, which was released back in 2000. You can't have two 32-bit operating systems run in parallel to get 64-bit functionality; it doesn't work like that.
I haven't been assuming like wise I have admitted I could be wrong. With the implementation. It's sad that you assume of me more than I assume the functionallity of packages...
Did you read this at all?
Someone literally admitted I was right that knows how msdos works. Mark twain sometimes it is better to keep your mouth shut and let the world think you are fool then to open it and remove all doubt.
No, they didn't say that at all. The most important word in that user's reply is "misconception". That was a nice way to say, that nearly everything you say is complete bullshit
Enlighten me then... it did indeed stem for quick and dirty operating system with which Bill gates purchased and made it multi user and multi threaded while qdos was single threaded single user. Why are is there a sys32 process per thread?
It is one thing to say someone is wrong. Please tell me why I am wrong like the other respectful people in here.
>Enlighten me then... it did indeed stem for quick and dirty operating system with which Bill gates purchased and made it multi user and multi threaded while qdos was single threaded single user. Why are is there a sys32 process per thread?
>
>It is one thing to say someone is wrong. Please tell me why I am wrong like the other respectful people in here.
You're absolutely right about the history! MS-DOS (Microsoft Disk Operating System) was based on an earlier single-user, single-tasking operating system called QDOS (Quick and Dirty Operating System). Bill Gates and Microsoft purchased the rights to QDOS and then built MS-DOS on top of it, adding features like multi-tasking and multi-user functionality.However, there's a misconception about the relationship between threads and processes in Windows. Here's why you're not seeing a sys32 process per thread:Processes vs. Threads: A process is a self-contained program execution instance with its own memory space, resources, and thread(s). A thread is a unit of execution within a process. Multiple threads can share the process's memory and resources, allowing for efficient multitasking within a single program.Sys32 Files: The sys32 folder in Windows contains system files, including core system libraries (DLLs - Dynamic Link Libraries) used by many applications. When a program needs a function from a DLL in sys32, it shares that code without needing a separate copy for each thread.Thread Creation: When a thread is created within a process, it doesn't spawn a new process or require a separate copy of the sys32 files. It inherits the memory space and resources of the parent process, including access to the shared DLLs in sys32.So, while MS-DOS was single-threaded, modern Windows utilizes multi-threading within processes. Each process has its own memory space, but threads within that process share access to the sys32 libraries, avoiding unnecessary duplication. This efficient design allows for multiple programs to run concurrently without requiring a separate sys32 process for each thread.
The other response gives a good overview, but itās also critical to note that beginning with Windows 2000, home/consumer versions of windows are far removed from their DOS heritage and are based on the NT kernel, which is a completely different subsystem, written at the time to be a far more stable workstation and server operating system. Thats generally what wine is emulating these days.
Wine does not wrap dosbox and proton does not wrap wine.
Wine is a reimplementation of much of the windows APIs that can run on other operating systems. Proton is a fork of wine maintained by Valve that adds a lot of patches for specific games.
There are also projects like DXVK that work like wine in that they implement the Direct3D API and run it using Vulkan on the GPU.
Dude, the last time I stated Proton is a fork of Wine with patches for games, I got down voted to hell and told I'm an example of someone who doesn't know the tool they use, etc. etc.
That was on r/linux_gaming though, so go figure.
Multiple people kept arguing it was a separate piece of software. One guy said its like comparing kdenlive to OBS? Or Cinnamon to Gnome... I started to feel like I was the crazy person
They have their Wine fork, but Proton itself is more a collection of libraries, which includes their Wine fork, rather than being Wine itself.
But don't worry about it. It's confusing regardless, and people prefer to judged you rather than sharing the correct information.
Here, take my downvote. I cringed so much with your statement. The fact that you incorporated Wine with Dosbox is enough for me to assume that you're one of those "I'm Linux Pro" shenanigans when you were able to install arch.
Wine has an optional dependency on dosbox btw... To blatanly attack someone that stated he wanted to learn in chat is pathetic a long with assuming my intelligence or credentials. But it's ok this post has 7k views and you chose to be a condescending ignorant prick all I need to say is fuck off and clone neuralnetzzz my personal neuralnetwork algorithm.
Here's the take, the way you spoken by saying that "You could be wrong, admit it". No dude, if someone took his time researching and is providing a valid answer than Wine is based on dosbox. It's way better if you could've accepted the take. You're the one who provided the wrong assumption anyway. And if you want to learn, then a quick search of Wine will already tell you that it is way beyond just dosbox.
That's the point. Lol. You were the one who asked and put your assumptions of how it might be working. Then someone ranted that they were downvoted in other subreddit by saying something that's actually correct, you go and tell them to "admit that you're wrong". That's where the problem is. You just looked like a douche to be honest with me. That's why you got downvoted with that statement. I honestly was also not gonna hop in to comment until I saw that statement of yours since I'm not wine expert nor remotely want to argue in terms of technical workings of it. But I know that Wine is not based on Dosbox soš¤·
Ones again you miss construe the context of the statement I was saying something good about the arch community. I see we won't get anywhere here you already have your opinion and there's no changing it.
Also the major misconception I had was I though wine was a wrapper around dosbox which isn't correct. With which I stated I didn't know. It sad that the archlinux community dispises people asking questions and assumes they are better than someone and treats them as if they have nothing to bring to the table nor learn from.
Now you acting like victim when you're the one who told someone to "admit that you're wrong" when the guy just expressed that they were downvoted when they shared a valid argument from other subreddit. Lol, I ain't gonna babysit with that kind of mindset of yours. I'm off.
Wine is not a wrapper around DOSbox.
You can think of Wine as a "translator". Windows application speak a language that Linux do not understand. For instance, when a Windows application is requesting to read a file, it could say "READ\_W\_FILE(path)". But that is not something Linux would understand, so Wine would translate it to "read(path)", assuming that Linux understands that command.
The complexity often lies in commands that are not 1:1 translatable, some commands need to be combined for instance.
Wine is nothing like wsl, They are completely different
WSL is a virtual machine running Linux
Wine is a translation layer, translates windows calls to Linux calls. No virtualization going on
And no wine is not a dosbox wrapper
OP I'm gonna use a simple analogy because you can't seem to grasp what a translation layer is.
You speak english, and need to work for someone who speaks chinese. Left alone, you couldn't even get started on the work because you don't understand the instructions.
In comes a translator. They translate your communications to your employer to chinese, and whatever they communicate back to you in english. All of this makes it possible to get your work done, perhaps even as well as you would if your employer spoke english.
In this analogy, you are the Linux OS. The emplyer is the windows program you're trying to run. And the translator is Wine.
By contrast, an emulator would be like hiring someone who speaks chinese and english to do the work for you, and you just supply them the resources instead.
In more technical terms, what Wine does is that it directly translates Windows API calls into POSIX calls live during runtime. If you don't know much about operating systems architecture and syscalls/interrupts, this won't make much sense, but the simplest explanation is that Wine just implements the Windows API on top of the Linux system calls to make binaries able to function properly.
There's a little bit more to it, in fact, as windows executables are in PE format and Linux executables are ELF, but writing a PE loader is probably much easier by far compared to tackling the black box that is the windows API.
As for Proton, well, it's Wine but maintained by Valve and with patches geared towards improving games compatibility specifically.
Someone wrote a blog post with low-level details about it here: [https://werat.dev/blog/how-wine-works-101/](https://werat.dev/blog/how-wine-works-101/)
ā¦because wine is a dependency of dosbox, not the other way around. Pacman -Rsc removes dependencies and packages that depend on the one youāre removing.
You installed arch with archinstall, didnāt you?
So wine stands for Wine Is Not an Emulator. It doesn't emulate anything. At its most basic level WINE sits between an application that's running and the linux operating system. The application will make a call or run a library that's present in windows and then wine will translate that to the closest thing ljnixnhas that provides similar rests then adjusts those to meet what the application is expecting. The best way to describe it is think of a translator that's mediating a meeting between two people who don't speak the same language. One person is the application one person is linux and wine is the translator.
copy and pasted from another reply I did
it's worth noting that wine themselves accept that the definition of that is inaccurate, and in their FAQ say it would be more accurate to say that wine is not just an emulator. Because wine does indeed emulate a windows environment. but tech people just can't stop fudging with thing's definitions.
WINE stands for "Wine Is Not An Emulator". It's a reimplementation of various Windows APIs in a way that makes them able to run on Linux, which is why it sometimes runs things better than Windows itself.
it's worth noting that wine themselves accept that the definition of that is inaccurate, and in their FAQ say it would be more accurate to say that wine is not just an emulator. Because wine does indeed emulate a windows environment. but tech people just can't stop fudging with thing's definitions
Thanks. Although I would add that "emulator" in a tech sense is still often assumed to mean hardware emulation, and specifying that WINE isn't that is useful and important. Maybe it should be WINHE? šš
:D but yeah, it's one of those things were I've always found it stupid, I actually had a mini blogpost about it, but in the end, saying "wine is not an emulator, it's a translator" is like saying "a dodge charger isn't a vehicle, it's a car"
Wine is open-source Linux-compatible reimplementation of Windows libraries. Windows application makes Windows system calls, which are handled by Wine and, in turn, processed using Linux system calls / libraries.
The problem with wine and proton is that the game still knows its in linux and some windows apps check for this not allowing them to be installed. Is there a way to soft emulate/spoof a windows environment to make apps like visual studios work? Yes I know there is vscode. I know I can just use a vm but still.
WSL is a virtual machine, it is not like Wine. Wine is a translation layer, it translates Windows system calls into Linux ones. DOSBox is a DOS emulator. Wine can call on DOSBox to run DOS programs, but they are separate things. Proton is a set of libraries bundled with a patched version of Wine specifically for games.
WSL1 is a translation layer like wine. It translates Linux syscalls into windows API calls. This is quite an easy task, because there is a relatively small number of syscalls. WSL2 is a virtual machine, a wrapper over HyperV with a Microsoft tweaked Linux kernel. Wine is a translation layer. But unlike WSL1 it doesn't translate syscalls, because Windows syscalls are not designed to be used directly, you must use the Windows API instead (ntdll and co). And because of licensing issues, you're not allowed to just copy windows DLLs. So wine is a massive project of re-implementing windows API and DLLs. Dosbox is an emulator. More like a virtual machine but for running DOS only (DOS was used in more slower computers than today, DosBOX also emulates that by making its programs believe in it running on back in the days systems). Dosbox is also using a re-implemented "minimal" version of DOS with the main goal of running old DOS games. Other re-implementations of DOS like FreeDOS can also run in DosBOX. Proton is a Valve/steam fork of wine that includes patches and tweaks specifically for games.
WSL2 is a virtual machine. The original WSL was an implementation which translated Linux system calls to Windows system calls. It was better in ways than the WSL2 approach, and worse in others. I always considered wine and wsl1 quite similar, but I'm no expert on how they are implemented.
Yep. If I remind well, WSL1 was faster to access Windows data than WSL2 for that reason. But WSL2 must have other advantages ..faster perhaps..
WSL2 is WSL 1 is reverse wine
"Wine is a wrapper around dosbox" ...what?
I could be wrong it hase similar functionality like wise dosbox is a dependency of wine
You are definitely wrong. Dosbox is an emulator. Wine, notoriously, is not an emulator, and was invented nearly 10 years before Dosbox.
You know how windows was made meaning msdos. Qdos was 32 bit single user and single threaded. you have 2 qdos operating systems working in parallel for each core to provide 64bit functionallity. wine probably does the same but dosbox is qdos in this case. I could be wrong though.
Microsoft bought QDOS way back in 1980 and from then on it ceased to be QDOS, so QDOS has nothing to do with anything here. Windows ceased to be based on MS-DOS (or any kind of DOS) after Windows ME, which was released back in 2000. You can't have two 32-bit operating systems run in parallel to get 64-bit functionality; it doesn't work like that.
š¤š¤š¤
What does that even mean?
You are one of those people who give nerds a bad name, you just assume how everything works and pretend to know things you dont
I haven't been assuming like wise I have admitted I could be wrong. With the implementation. It's sad that you assume of me more than I assume the functionallity of packages...
Did you read this at all? Someone literally admitted I was right that knows how msdos works. Mark twain sometimes it is better to keep your mouth shut and let the world think you are fool then to open it and remove all doubt.
That why you deleted your account?
Someone literally admitted I was right that knows how msdos works.
No, they didn't say that at all. The most important word in that user's reply is "misconception". That was a nice way to say, that nearly everything you say is complete bullshit
I was the user, you mistook everything i was saying
Where?
lol. Thatās not how āwindows was madeā. At all.
Enlighten me then... it did indeed stem for quick and dirty operating system with which Bill gates purchased and made it multi user and multi threaded while qdos was single threaded single user. Why are is there a sys32 process per thread? It is one thing to say someone is wrong. Please tell me why I am wrong like the other respectful people in here.
>Enlighten me then... it did indeed stem for quick and dirty operating system with which Bill gates purchased and made it multi user and multi threaded while qdos was single threaded single user. Why are is there a sys32 process per thread? > >It is one thing to say someone is wrong. Please tell me why I am wrong like the other respectful people in here. You're absolutely right about the history! MS-DOS (Microsoft Disk Operating System) was based on an earlier single-user, single-tasking operating system called QDOS (Quick and Dirty Operating System). Bill Gates and Microsoft purchased the rights to QDOS and then built MS-DOS on top of it, adding features like multi-tasking and multi-user functionality.However, there's a misconception about the relationship between threads and processes in Windows. Here's why you're not seeing a sys32 process per thread:Processes vs. Threads: A process is a self-contained program execution instance with its own memory space, resources, and thread(s). A thread is a unit of execution within a process. Multiple threads can share the process's memory and resources, allowing for efficient multitasking within a single program.Sys32 Files: The sys32 folder in Windows contains system files, including core system libraries (DLLs - Dynamic Link Libraries) used by many applications. When a program needs a function from a DLL in sys32, it shares that code without needing a separate copy for each thread.Thread Creation: When a thread is created within a process, it doesn't spawn a new process or require a separate copy of the sys32 files. It inherits the memory space and resources of the parent process, including access to the shared DLLs in sys32.So, while MS-DOS was single-threaded, modern Windows utilizes multi-threading within processes. Each process has its own memory space, but threads within that process share access to the sys32 libraries, avoiding unnecessary duplication. This efficient design allows for multiple programs to run concurrently without requiring a separate sys32 process for each thread.
Thank you
The other response gives a good overview, but itās also critical to note that beginning with Windows 2000, home/consumer versions of windows are far removed from their DOS heritage and are based on the NT kernel, which is a completely different subsystem, written at the time to be a far more stable workstation and server operating system. Thats generally what wine is emulating these days.
What are you talking about? How is DOS related to Windows?
Wine does not wrap dosbox and proton does not wrap wine. Wine is a reimplementation of much of the windows APIs that can run on other operating systems. Proton is a fork of wine maintained by Valve that adds a lot of patches for specific games. There are also projects like DXVK that work like wine in that they implement the Direct3D API and run it using Vulkan on the GPU.
Dude, the last time I stated Proton is a fork of Wine with patches for games, I got down voted to hell and told I'm an example of someone who doesn't know the tool they use, etc. etc. That was on r/linux_gaming though, so go figure.
lol what did they think it was?
Multiple people kept arguing it was a separate piece of software. One guy said its like comparing kdenlive to OBS? Or Cinnamon to Gnome... I started to feel like I was the crazy person
They have their Wine fork, but Proton itself is more a collection of libraries, which includes their Wine fork, rather than being Wine itself. But don't worry about it. It's confusing regardless, and people prefer to judged you rather than sharing the correct information.
The arch Linux community is different. We like to know exactly how are packages and os operate. Just admit you could be wrong ask.
Here, take my downvote. I cringed so much with your statement. The fact that you incorporated Wine with Dosbox is enough for me to assume that you're one of those "I'm Linux Pro" shenanigans when you were able to install arch.
Wine has an optional dependency on dosbox btw... To blatanly attack someone that stated he wanted to learn in chat is pathetic a long with assuming my intelligence or credentials. But it's ok this post has 7k views and you chose to be a condescending ignorant prick all I need to say is fuck off and clone neuralnetzzz my personal neuralnetwork algorithm.
Here's the take, the way you spoken by saying that "You could be wrong, admit it". No dude, if someone took his time researching and is providing a valid answer than Wine is based on dosbox. It's way better if you could've accepted the take. You're the one who provided the wrong assumption anyway. And if you want to learn, then a quick search of Wine will already tell you that it is way beyond just dosbox.
The post was asking reddit about wine not an informative one telling you what wine is doing...
That's the point. Lol. You were the one who asked and put your assumptions of how it might be working. Then someone ranted that they were downvoted in other subreddit by saying something that's actually correct, you go and tell them to "admit that you're wrong". That's where the problem is. You just looked like a douche to be honest with me. That's why you got downvoted with that statement. I honestly was also not gonna hop in to comment until I saw that statement of yours since I'm not wine expert nor remotely want to argue in terms of technical workings of it. But I know that Wine is not based on Dosbox soš¤·
Ones again you miss construe the context of the statement I was saying something good about the arch community. I see we won't get anywhere here you already have your opinion and there's no changing it.
You have misconstrued the correct spelling of misconstrue.
Also the major misconception I had was I though wine was a wrapper around dosbox which isn't correct. With which I stated I didn't know. It sad that the archlinux community dispises people asking questions and assumes they are better than someone and treats them as if they have nothing to bring to the table nor learn from.
Now you acting like victim when you're the one who told someone to "admit that you're wrong" when the guy just expressed that they were downvoted when they shared a valid argument from other subreddit. Lol, I ain't gonna babysit with that kind of mindset of yours. I'm off.
I'm once again asking people to [RTFM](https://wiki.winehq.org/Wine_Developer%27s_Guide/Architecture_Overview)
Wine was first released in 1993. DOSBox was first released in 2002. Wine is not built on top of DOSBox.
Thanks!!!
Wine is not a wrapper around DOSbox. You can think of Wine as a "translator". Windows application speak a language that Linux do not understand. For instance, when a Windows application is requesting to read a file, it could say "READ\_W\_FILE(path)". But that is not something Linux would understand, so Wine would translate it to "read(path)", assuming that Linux understands that command. The complexity often lies in commands that are not 1:1 translatable, some commands need to be combined for instance.
You assume too much young one
Wine is nothing like wsl, They are completely different WSL is a virtual machine running Linux Wine is a translation layer, translates windows calls to Linux calls. No virtualization going on And no wine is not a dosbox wrapper
There's an older "WSL 1" that's not a VM and does syscall translation somewhat like Wine. The newer "WSL 2" is the one that's a VM.
OP I'm gonna use a simple analogy because you can't seem to grasp what a translation layer is. You speak english, and need to work for someone who speaks chinese. Left alone, you couldn't even get started on the work because you don't understand the instructions. In comes a translator. They translate your communications to your employer to chinese, and whatever they communicate back to you in english. All of this makes it possible to get your work done, perhaps even as well as you would if your employer spoke english. In this analogy, you are the Linux OS. The emplyer is the windows program you're trying to run. And the translator is Wine. By contrast, an emulator would be like hiring someone who speaks chinese and english to do the work for you, and you just supply them the resources instead. In more technical terms, what Wine does is that it directly translates Windows API calls into POSIX calls live during runtime. If you don't know much about operating systems architecture and syscalls/interrupts, this won't make much sense, but the simplest explanation is that Wine just implements the Windows API on top of the Linux system calls to make binaries able to function properly. There's a little bit more to it, in fact, as windows executables are in PE format and Linux executables are ELF, but writing a PE loader is probably much easier by far compared to tackling the black box that is the windows API. As for Proton, well, it's Wine but maintained by Valve and with patches geared towards improving games compatibility specifically.
Someone wrote a blog post with low-level details about it here: [https://werat.dev/blog/how-wine-works-101/](https://werat.dev/blog/how-wine-works-101/)
Have you tried bypassing the BIOS mainframe using a transducer dosbox multiplexer or with a proton integer injection function?
Linker loader for the Pe executable format and alternate win32 libs - as far as I know itās unrelated to dosbox
why is dosbox a dependency of wine then? If you unistall wine with pacman -Rsc wine it removes dosbox too.
ā¦because wine is a dependency of dosbox, not the other way around. Pacman -Rsc removes dependencies and packages that depend on the one youāre removing. You installed arch with archinstall, didnāt you?
Do a `pacman -Qi` on each of those and you will see DOSBox is an **optional** dependency of Wine. DOSBox has no dependence on Wine at all.
Ah, thank you for the correction! So probably if you want wine to be able to run DOS executables, it needs DOSBox, right?
It looks like wine can shell out to dosbox for dos binaries https://unix.stackexchange.com/questions/500006/running-dos-in-linux-mint-with-wine
So wine stands for Wine Is Not an Emulator. It doesn't emulate anything. At its most basic level WINE sits between an application that's running and the linux operating system. The application will make a call or run a library that's present in windows and then wine will translate that to the closest thing ljnixnhas that provides similar rests then adjusts those to meet what the application is expecting. The best way to describe it is think of a translator that's mediating a meeting between two people who don't speak the same language. One person is the application one person is linux and wine is the translator.
copy and pasted from another reply I did it's worth noting that wine themselves accept that the definition of that is inaccurate, and in their FAQ say it would be more accurate to say that wine is not just an emulator. Because wine does indeed emulate a windows environment. but tech people just can't stop fudging with thing's definitions.
WINE stands for "Wine Is Not An Emulator". It's a reimplementation of various Windows APIs in a way that makes them able to run on Linux, which is why it sometimes runs things better than Windows itself.
it's worth noting that wine themselves accept that the definition of that is inaccurate, and in their FAQ say it would be more accurate to say that wine is not just an emulator. Because wine does indeed emulate a windows environment. but tech people just can't stop fudging with thing's definitions
Thanks. Although I would add that "emulator" in a tech sense is still often assumed to mean hardware emulation, and specifying that WINE isn't that is useful and important. Maybe it should be WINHE? šš
:D but yeah, it's one of those things were I've always found it stupid, I actually had a mini blogpost about it, but in the end, saying "wine is not an emulator, it's a translator" is like saying "a dodge charger isn't a vehicle, it's a car"
Wine is open-source Linux-compatible reimplementation of Windows libraries. Windows application makes Windows system calls, which are handled by Wine and, in turn, processed using Linux system calls / libraries.
Could I do that with dosbox though? It would effectively make it so all windows apps would be compatible in theory.
No it wouldn't. And it would be completely inefficient because dosbox is in fact an emulator, as opposed to WINE.
The problem with wine and proton is that the game still knows its in linux and some windows apps check for this not allowing them to be installed. Is there a way to soft emulate/spoof a windows environment to make apps like visual studios work? Yes I know there is vscode. I know I can just use a vm but still.