X.Org Server Development Hit A Decade High For The Number Of Commits In 2024

[Weasel]

Going to normal user32 API is going to the Microsoft graphical toolkit. That is a interface before DWM API exists on Windows. Yes the syscalls for that information are not DWM syscalls.

Weasel this does not match what you have been doing with X11. X11 you have been using debugging APIs these are not meant to be generally used and have some serous design flaws.

user32 API include some API for assistive technologies. Yes Microsoft precursor to MSAA.

Remember I said windows does not have proper automation APIs. It has hack attempts and not just one attempt Weasel.

Weasel so you don't ask for Microsoft to put user32 functionality in the DWM API right. Wayland Protocol is equal to the DWM API.

But Wayland does not work with the old "user32" interface and that's the problem. But in this bad analogy you'd have to implement X11 protocol in Wayland.

[oiaohm]

But Wayland does not work with the old "user32" interface and that's the problem. But in this bad analogy you'd have to implement X11 protocol in Wayland.

X11 on Wayland is in fact not a problem Weasel. This is you not being a old Unix power user. Notice how x.org has xnest and Xephyr and that xwayland is extend of this. Yes xnest, Xepher and xwayland all have a virtual desktop. Yes basically the stunt of one master image is what they work with coordinates from.

https://github.com/KDE/xwaylandvideobridge

The biggest issue with xwayland was 1 not being able to see wayland applciations 2 not being able to control wayland applications.

Before Nvidia stuffed it up old school Unix power users with use to nesting X11 instances for automation. Yes so that you could avoid opps I did something while automation was running. Yes this was also relative positioning.

Wine project virtual desktop is also relative positioning and it runs user32 interfaces for automation yes this is X11 or Wayland.

The reality is the user32 or the x11 case both don't require the Wayland protocol altered at all as long as you nest what you are automating. Yes Xwayland is always nested.

https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/264

Yes this is also following the nested model but this is not so user32/x11 application work.

DWM on windows does not have all the features of user32. Yes Wayland compositors don't have to have all the features of user32 or X11 to allow windows applications or X11 applications to work.

Weasel I mentioned 3 different solutions for automation with wayland. Gnome being dbus at-spi2 stuff(yes they are looking to add this to at-spi2 what dogtail is using), KDE being their kwin scripts and wlroots in protocol.

There is a 4 in fact the weston one has not been built out

https://vignatti.wordpress.com/2013/03/05/ui-customization-on-wayland/

The weston had the idea you would built a custom .so shell plugin for automation. Yes weston support turtles all the way down stacking for a reason.

Yes the weston, gnome and kde options all have the means to support blocking mid step interference from happening.

Weasel notice something old Unix power users you nest what you are automating. Nest is so you can allow the automation to be doing it thing while you are working on something else on the system and not interfere with each other. AHK under windows is not built to use nesting because windows has not had that feature.

It is annoying that gnome mutter/gnome shell when nested does not support window/virtual desktop resizing like KDE or Sway or Weston does because this would make dogtail lot more use-able.

Reality I don't care if I have to run particular Wayland compositor to have automation as long as that compositor supports me resizing its virtual desktops when nested. Yes coming from being a Unix power user I am use to nesting for automation and use to the advantages that gives.

[oiaohm]

Writing the script and automating with a macro should be done as fast as possible (including "not thinking" much about it before-hand, like overall design and whatever crap). It's not something you release to the public as production ready automation. It's for you to simplify your life so it should be done as fast as possible and as simple as possible. After all it's all about saving your time and ONLY your time. Otherwise you lose more time writing that shit than the time you save.

Weasel there is such thing as too simple. Unix power users doing this automation would majority of the time nest X11 servers. Yes you want to prevent spending more time writing the automation than you will save by running it. You don't really want automation that your automation and your can end up conflicting with each other. A little thinking before hand with automation is a good thing to make sure you and your automation are not going to clash with each other and possible cause something totally not expected to happen.

Yes you run a macro you happen to attempt to do something on a pop up that just came up so moving the mouse pointer just as the automation does a click and that pop up was something important you absolutely did not want to click so now spending a few hours fixing your system for example weasel. Yes nested the automated operations are not send to applications outside the nest. So you go to the outside pop up and nothing bad happens. This is why Unix power users look at what Windows power users do and go are you nuts because you are not nesting to contain what the automation can mess with so risk having to spend fixing stuff for hours you would not have if you had nested in the first place..

Weasel "proprietary app" what one. Remember you can automate inside xwayland or wine virtual desktop on top of Wayland. I don't know of native proprietary apps needing this unless you are talking about automating Linux native games??? There are ways using libsdl todo a lot of Linux native games of course this is only going to work with single player games running locally because other wise it will detect as cheating.

Yes this nesting but is those coming from a Unix background are not going care if it only one particular compositor or not that can do it. Because what we use will be the compositor we use to nest with when we want to automate something.

Weasel this should also explain how Nvidia has managed to annoy me for over 15 years that their opengl drivers have not supported nested instances.

[Weasel]

X11 on Wayland is in fact not a problem Weasel. This is you not being a old Unix power user. Notice how x.org has xnest and Xephyr and that xwayland is extend of this. Yes xnest, Xepher and xwayland all have a virtual desktop. Yes basically the stunt of one master image is what they work with coordinates from.

https://github.com/KDE/xwaylandvideobridge

The biggest issue with xwayland was 1 not being able to see wayland applciations 2 not being able to control wayland applications.

No you don't get it. I said X11 protocol in Wayland, not the compositor, in the protocol itself. user32 is NOT a compatibility layer or API. For XWayland, the app would have to be targetted for X11, not Wayland, so it's not Wayland. Even if it ends up using XWayland.

I don't care about nesting. Windows doesn't nest anything, you can even child your window to another app's window, both using wildly different frameworks or whatever, say one from 2000s and one from 2020s. They're not separate from each other, like XWayland and Wayland apps are.

Nesting is the lazy answer to a problem that Wayland refuses to fix. It sucks, just like containers.

[oiaohm]

No you don't get it. I said X11 protocol in Wayland, not the compositor, in the protocol itself. user32 is NOT a compatibility layer or API.

You are wrong on that bit about user32 not being a compatibility layer/API.

https://learn.microsoft.com/en-us/sysinternals/resources/inside-native-applications

Windows NT designed OS this includes the windows 7-11 stuff native applications are not Win32. User32 is a part of the Win32 api that is in fact a compatibility layer/subsystem under Windows NT design. User32 was not a compatibility layer on the Windows 9x/3.1x operating systems. Yes anything based of NT design its been a compatibility layer like it or not..

I don't care about nesting. Windows doesn't nest anything, you can even child your window to another app's window, both using wildly different frameworks or whatever, say one from 2000s and one from 2020s. They're not separate from each other, like XWayland and Wayland apps are.

Nesting is the lazy answer to a problem that Wayland refuses to fix. It sucks, just like containers.

There is a problem here. Xnest with X11 server predates Microsoft existing as a Company. Chroot the precursor to containers also predates Microsoft existing as a company.

Yes you are a Windows power user not use to nesting. Xwayland is no different to running xnest or xephyr under X11 with the isolation.

There is a problem with the Windows design of let OS child of any random other window this can cause never ending loops of moving windows when two applications are totally trying align themselves differently from each other. This problem had happened under X11 as well.

https://users.cs.utah.edu/~elb/folklore/xerox.txt

You did not have some pain in a but think it would be a good idea to implement the problem Robin Hood to Friar Tuck but for the graphical world. Yes someone did that on X11/linux in 2008 just so they could delay an exam(yes end with themselves in jail with tones of time to study).

Yes Wayland design was that the compositor would have absolute control of window placement. This is why weston support a .so plugin and is stackable

https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/264

Weasel part of why above is taking so long is that Linux/Unix world has seen examples of hostile abuse of window placement and decided to prevent it. The tricky part is working out how to give back enough while keeping means to prevent the hostile abuse.

As you said Windows is not designed for nesting and is not designed to be able to contain some application deciding to be a evil pain in the but.

For automation using nesting wayland compositors/x11 servers also allow you to cut/copy/paste/DnD in the nested area independent to what the operator is doing elsewhere on the system as well. Automation of applications it makes way more sense to nest than not nest. Weasel being a Windows power user you are absolute not use using nesting and try to say it a bad idea without looking at the functionality and stability improvements to automation nesting gives. You are absolutely not use to creating transfer portals for clipboards and the like between nested area and outside.

264 if implemented gives control over what application can child off what other application. This is important bit of security we need. You need to be able to block two problem child applications from being able to child off each other. Yes I would say the current Wayland protocol design is a little bit of a sledge hammer but it does achieve the blocking of applications child off each other so blocking harmful child window interaction..

Weasel this is don't throw the baby out with the bath water. The important bit is control of what applications can child off each other to prevent malicious use. Weasel the user32 does not have tools for this problem. X11 protocol with nesting does have some tools to deal with these problems but was a need to make it more generic.

Weasel also remember to get into wayland protocol or xdg-desktop-portal or at-spi2 there need to be functionally proven implementations.

Weasel you have always saying windows/X11 can do this never asking should this always be allowed to find the horrible answer is that it should not be always allowed so there is security required here. Wayland protocol all the way along has been known for heavy handed security implementation.

[Weasel]

You are wrong on that bit about user32 not being a compatibility layer/API.

https://learn.microsoft.com/en-us/sysinternals/resources/inside-native-applications

Windows NT designed OS this includes the windows 7-11 stuff native applications are not Win32. User32 is a part of the Win32 api that is in fact a compatibility layer/subsystem under Windows NT design. User32 was not a compatibility layer on the Windows 9x/3.1x operating systems. Yes anything based of NT design its been a compatibility layer like it or not..

No you are wrong, once again you link something without reading it, or not understanding it.

Win32 is a subsystem designed for apps. The NT native subsystem is not intended for apps since it's not even documented. It's intended for Windows internal use. That's literally what your link said if you bothered to read it.

I don't think you understand what "compatibility layer" means. Win32 is the direct layer apps target, not a compatibility one.

The NT subsystem might also change in subsequent versions since apps are not supposed to use it (being undocumented and all).

There is a problem here. Xnest with X11 server predates Microsoft existing as a Company. Chroot the precursor to containers also predates Microsoft existing as a company.

Yes you are a Windows power user not use to nesting. Xwayland is no different to running xnest or xephyr under X11 with the isolation.

There is a problem with the Windows design of let OS child of any random other window this can cause never ending loops of moving windows when two applications are totally trying align themselves differently from each other. This problem had happened under X11 as well.

https://users.cs.utah.edu/~elb/folklore/xerox.txt

You did not have some pain in a but think it would be a good idea to implement the problem Robin Hood to Friar Tuck but for the graphical world. Yes someone did that on X11/linux in 2008 just so they could delay an exam(yes end with themselves in jail with tones of time to study).

Yes Wayland design was that the compositor would have absolute control of window placement. This is why weston support a .so plugin and is stackable

https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/264

Weasel part of why above is taking so long is that Linux/Unix world has seen examples of hostile abuse of window placement and decided to prevent it. The tricky part is working out how to give back enough while keeping means to prevent the hostile abuse.

As you said Windows is not designed for nesting and is not designed to be able to contain some application deciding to be a evil pain in the but.

Dude I don't care about any problem it exposes, my point was to prove your statement wrong that you only do it via nesting. Windows doesn't nest shit. That's the end of it.

Containers and sandboxes for compatibility are the real pain in the butt. Those things should only be done for security or isolation.

Weasel you have always saying windows/X11 can do this never asking should this always be allowed to find the horrible answer is that it should not be always allowed so there is security required here. Wayland protocol all the way along has been known for heavy handed security implementation.

No shit, that's why it's forever crippled unlike every other display stack in every other desktop OS. "Security" bullshit.

But for this crap Wayland it's obviously not good enough to let the user choose his "security" settings, it must dictate everything and disallow it completely. macOS for example has even better security but it allows the user to set permissions.

A concept Wayland cannot comprehend obviously, since it's designed by GNOME tards and we all know how friendly they are with respect to user choice rather than forcing them to do what their pathetic ways are. Who would've thought right?

[oiaohm]

No you are wrong, once again you link something without reading it, or not understanding it.

Win32 is a subsystem designed for apps. The NT native subsystem is not intended for apps since it's not even documented. It's intended for Windows internal use. That's literally what your link said if you bothered to read it.

I don't think you understand what "compatibility layer" means. Win32 is the direct layer apps target, not a compatibility one.

The NT subsystem might also change in subsequent versions since apps are not supposed to use it (being undocumented and all).

Weasel you have a few thing wrong. NT native API is not a subsystem.

https://en.wikipedia.org/wiki/Windows_Native_API

Was NT native API always undocumented this is not in fact true. Windows NT 3.5 did in fact document the Windows Native API because Microsoft at that time presumed people might want to write their own subsystems including graphical ones.

Remember Windows NT use to have OS/2 and Posix subystems written by Microsoft next to the Win32 one.

Win32 Weasel like it or not is not a direct layer on Windows NT designed OS. Yes Microsoft has chosen to keep NT native API undocumented and out of hands of most application developers.

Weasel Nt native API is what your Windows NT style OS subsystems are written in. Early points of Windows NT history yes NT native API was meant to have applications written using it limited to the functions exposed by ntdll.dll.

Yes the win32 subsystem is a compatibility layer between the application and the changing NT native APi interfaces. Microsoft decides you are not trusted to code in the NT native API so hide the documentation.

Dude I don't care about any problem it exposes, my point was to prove your statement wrong that you only do it via nesting. Windows doesn't nest shit. That's the end of it.

Containers and sandboxes for compatibility are the real pain in the butt. Those things should only be done for security or isolation.

Not weasel I did not say it cannot be done other ways. You said security or isolation. I nest automated because I want automated script actions isolated so bad things cannot happen.

The automation can only interact with the application that it intended to interact with with nesting.

Your windows example means nothing to me because its not a secure or safe way of doing it.

Containers and sandboxes for compatibility where chosen for Unix/Linux/BSD because the reality is some old application that you are running for compatibility will normal be using out of date libraries and other parts with known security problems. So yes there is a security reason todo it this other way. Yes being a pain in the but also cause you to consider newer maintained application instead of keeping on using no longer maintained application. Path of least resistance is the path to the more up to date solution. There is logic here.

Microsoft logic is path of least resistance is the path that you will run applications well past the point you should and not consider replacing the application.

There are upsides and downsides from both design choices.

[Weasel]

Weasel you have a few thing wrong. NT native API is not a subsystem.

https://en.wikipedia.org/wiki/Windows_Native_API

Was NT native API always undocumented this is not in fact true. Windows NT 3.5 did in fact document the Windows Native API because Microsoft at that time presumed people might want to write their own subsystems including graphical ones.

Remember Windows NT use to have OS/2 and Posix subystems written by Microsoft next to the Win32 one.

Win32 Weasel like it or not is not a direct layer on Windows NT designed OS. Yes Microsoft has chosen to keep NT native API undocumented and out of hands of most application developers.

Weasel Nt native API is what your Windows NT style OS subsystems are written in. Early points of Windows NT history yes NT native API was meant to have applications written using it limited to the functions exposed by ntdll.dll.

Yes the win32 subsystem is a compatibility layer between the application and the changing NT native APi interfaces. Microsoft decides you are not trusted to code in the NT native API so hide the documentation.

Dude just stop, you have no fucking clue what compatibility layer means. user32 is THE proper interface for those apps, not a compatibility layer for "legacy" apps.

Quote from wikipedia:

In software engineering, a compatibility layer is an interface that allows binaries for a legacy or foreign system to run on a host system.

user32 is like using xlib to interface with Xorg instead of passing raw commands to it via the pipe or whatever. That's not a compatibility layer. Just fucking stop grasping at straws.

[oiaohm]

Dude just stop, you have no fucking clue what compatibility layer means. user32 is THE proper interface for those apps, not a compatibility layer for "legacy" apps.

Quote from wikipedia:

In software engineering, a compatibility layer is an interface that allows binaries for a legacy or foreign system to run on a host system.

That line is contains a mistake. Legacy should be deleted. Note the or. "an interface that allows binaries for foreign system to run on host system" This is what Windows subsystems are. Microsoft has made minwin versions of windows with no subsystems.

Weasel like it not user32 on Windows is technically a foreign system. Subsystems in Windows documentation are for foreign binary support by Microsoft own NT documentation. ntdll/nt native api is the non foreign API.

user32 is like using xlib to interface with Xorg instead of passing raw commands to it via the pipe or whatever. That's not a compatibility layer. Just fucking stop grasping at straws.

No it not. For the NT kernel the xlib equal is ntdll.dll. user32 due to being subsystem is closer to gtk/qt/toolkits on Linux/unix. user32 calls to kernel still go though ntdll.

Weasel stop not excepting reality. Linux equals to ntdll.dll is all the syscall stuff added to libc and libraries like libdrm. Linux has the functionality of ntdll spread over more than one .so. By the way ntdll.dll is very close to klibc. ntdll.dll is cut down libc with a non standard main entry point.

X11 on Linux is foreign system.

https://captmeelo.com/redteam/maldev/2022/05/10/ntcreateuserprocess.html

Here is a interesting one. Windows pure native API binary cannot be started by createprocess in fact it will complain that its not win32 but can be in fact started by ntcreateuserprocess. Yes a pure windows native APi has a entry point of "NtProcessStartup" not main that you are use to. Was this always the case no. If you go back to historic windows nt win32 createprocess could in fact start native api processes without error.

Weasel like it or not Microsoft wants to force developers to use the compatibility layer. By having majority of the application using a compatibility layer Microsoft can change kernel parts without disrupting the majority of applications. There is not 1 to 1 map of win32 functionality to native api calls.

Weasel something being a proper interface for an application does not mean it not also a compatibility layer.

The fact win32 is not in fact native on Windows because it designed to be foreign that we use now this is some of the reason why wine being a compatibility layer gets so performance close. Both wine and win32 subsystem of windows take compatibility layer overhead due to not being native so having to call other parts to get to kernel/graphical.

Weasel you have not considered that Microsoft developer making NT intentionally made all subsystems foreign binary. Also you don't want to consider that Microsoft keeps on wanting to block developers from writing windows native binaries because they want developers to code foreign not native and this is part of NT design.

Weasel I have looked under the hood here to see what is there and what under the hood gives a very different picture.