Microsoft Makes Open-Source Windows Forms, WinUI, WPF

[ssokolow]

The original X is not working fine this was covered in the 2013 video where they had in fact tried to find one thing that X11 server and protocol was doing right There is not a single thing X11 protocol is in fact doing 100 percent right. Lot of things correct 90 percent of time but wrong 10 percent of time.

Would that be Daniel Stone's talk, where he summed up the one X feature not overridden in a modern direct-rendered, composited desktop as "Terrible, terrible IPC" and pointed out the ridiculous number of unpredictably-latencied server round trips that occur just to render a simple text editor window?

[ssokolow]

?!??? Are you suggesting to use one compositor per application? Wow. Talk about retarded.

For Wine? No, it makes all the sense in the world.

Windows applications expect services that don't match the Linux kernel, so Wine provides a Windows kernel facade which runs as an application on the Linux kernel.

Windows applications expect compositor behaviour that doesn't match Wayland, so Wine can provide a Windows compositor facade which runs as a Wayland client.

Conceptually, it's no different than using XEmbed to wrap a frontend around MPlayer under X11. In fact, nested compositing is the officially recommended approach for replacing XEmbed.

[Weasel]

For Wine? No, it makes all the sense in the world.

Windows applications expect services that don't match the Linux kernel, so Wine provides a Windows kernel facade which runs as an application on the Linux kernel.

Of course it has to run a server to "emulate" the Windows kernel services. A kernel has persistent state across applications, so clearly a server is needed to do that in userspace. Obviously, that's the whole point of Wine: to integrate and run on Linux and Unix in userspace.

I mean, an alternative is to simply make a kernel module that implements the Windows kernel, but it wouldn't be Wine anymore, just call it "ReactOS Unix". Wine is all about integrating Windows userspace into Unix userspace. If you want real kernel-level stuff then use ReactOS.

Without integration you might as well run a freaking Virtual Machine. You guys are clearly missing the point of Wine.

Windows applications expect compositor behaviour that doesn't match Wayland, so Wine can provide a Windows compositor facade which runs as a Wayland client.

No you just need a userspace driver that does it (like wine's current winex11.drv). Obviously the driver will require features that Windows needs though, so Wayland is out of the question.

[ssokolow]

No you just need a userspace driver that does it (like wine's current winex11.drv).

Note that I said "can provide", not "should provide". I'm abstaining from making that judgment call here.

Obviously the driver will require features that Windows needs though, so Wayland is out of the question.

"Wayland is out of the question" is too strong a statement. There are always ways to work around platform limitations... it's just a question of what has to be traded away and what percentage of apps will take a hit to compatibility unless you enable the desktop-in-a-window option... similar to how Wine currently trades off between native window decorations and supporting Windows applications that want to overdraw theirs.

[Weasel]

"Wayland is out of the question" is too strong a statement. There are always ways to work around platform limitations... it's just a question of what has to be traded away and what percentage of apps will take a hit to compatibility unless you enable the desktop-in-a-window option... similar to how Wine currently trades off between native window decorations and supporting Windows applications that want to overdraw theirs.

I don't think you get it; the wineserver is needed for interoperability between applications. You don't need it if all you run is a single application per such session that's not aware of another one (it's the same as running each app in its own WINEPREFIX -- they won't be aware of each other, in the Windows sense of the term). Theoretically, in such a design you could store all "kernel stuff" in the app's address space and there would be no difference.

And when I said "out of the question" I meant using the current design of translating events and stuff in a (relatively simple) driver.

[ssokolow]

I don't think you get it; the wineserver is needed for interoperability between applications. You don't need it if all you run is a single application per such session that's not aware of another one (it's the same as running each app in its own WINEPREFIX -- they won't be aware of each other, in the Windows sense of the term). Theoretically, in such a design you could store all "kernel stuff" in the app's address space and there would be no difference.

And when I said "out of the question" I meant using the current design of translating events and stuff in a (relatively simple) driver.

I get it just fine. What I've been saying all along is that there's precedent for Wayland-compatible approaches in how Wine chose to solve other problems and that nested compositing is the recommended solution for implementing wrappers, as demonstrated by the advice to use it to replace XEmbed for things like MPlayer frontends.

[oiaohm]

I don't think you get it; the wineserver is needed for interoperability between applications. You don't need it if all you run is a single application per such session that's not aware of another one (it's the same as running each app in its own WINEPREFIX

Wineserver is need when running single applications as well. Items like registry access and locking around items like are done inside the wineserver.

https://linux.die.net/man/1/wineserver

Wineserver is your replacement to windows system services. There are very few windows applications don't use one of the system services features. If you start a clean wine prefix run 1 application if you see wineserver spin up application used something that used a system service. And wineserver going to spin up no matter what as the loader of wine access the registery to check on setting this will trigger the wineserver to start.

Wineserver is not just about interoperability between application. Its about emulating the basic features windows applications expect windows services to be providing be this kernel space or user space windows services..

[oiaohm]

The xorg developer in that video and his fans are dreaming that wayland would replace X11 and reduce programming work. They need to maintain two systems now, very clever. Wayland will go to the same garbage box as pulseaudio. There is not many native wayland apps, it is so popular.

Xwayland limitations have been useful. Xwayland has implemented X11 features on proven need. Has been used to prove particular X11 features are not required resulting more features being drop from the general X.org server.

Keeping the two systems of wayland and x.org X11 server has in fact reduced workload due to volume of code deleted from x.org X11 server in the process. More code has been deleted from x.org X11 server than what makes up the complete weston/wayland stuff.

There are other limitations like wayland allows per monitor DPI. X11 you will notice per monitor DPI is very hard to-do.

[Weasel]

Wineserver is need when running single applications as well. Items like registry access and locking around items like are done inside the wineserver.

Your point is? They wouldn't need to be done in the wineserver if you only ran one app.

Yeah of course they are done in the wineserver because Wine supports multiple processes. Thanks for the info Captain Obvious!

Wineserver is your replacement to windows system services.

No it's a replacement for the kernel, keeping persistent state across address spaces (apps). Locking items (your example) is in wineserver because another app has to know that one app locked it. Where do you think this state would otherwise be stored? Clearly it has to be out-of-process. If only ONE app ran under a wineprefix, then this locking state can simply be stored in app's address space and accessed like any global variable or whatever. (then wineserver would just become a library in the app's addressing space)

Of course I don't expect anything else from you, throwing random buzzwords around. Providing services is a generic term and it's not the "Windows services" one understands when talking about it (i.e. daemons). You see stuff like winedevice.exe and such, those are "system services".


Yes of course you could store such state in files for example (out of process), which is really no different than wineserver except it's even less efficient. You still need syscalls to write to the files and read them, just as you need syscalls to send requests to the wineserver and receive them. Can't be avoided, because again, it's more than one address space. Really basic stuff here.