On Fri May 22 12:20:02 2026 +0000, Jacek Caban wrote:
Why should it live on the unix side? That's where most of the logic already lives, including some of the logic that you are duplicating here, and it's not going away. Why would we split the logic when we don't need to? Instead of having a single module with the full picture, we'd end up with two modules and a non-obvious protocol between them. Having client IDs in the unixlib protocol simply seems much cleaner to me. I do not see why the PE side would need to know anything about IDs internal to Unix. There are cases where some split makes sense, for example for context handling. But in this case, I do not see any value added, thus my question. This is not the same thing as wow64 buffer tracking: it is not limited to WOW64 and it is not meant to create object wrappers. We only need integral name mapping, and we want it to be as lightweight as possible. We do not need all of them to be full wrappers. Whatever you do on the PE side can be done on the Unix side as well. GLsync handle allocation, which is on the PE side already will also be moved to the display lists for correctness. Maybe they should be on the Unix side too. I don't think it makes sense: the current WOW64 buffer wrappers are about wrapping the buffer *storage*, and managing their mapped pointer location, which is also some WOW64-only logic. The wrappers are allocated only when the buffer storage is allocated, which is *not* the same thing as the buffer *names*, or the buffer *objects*. Buffer *names*, and *objects*, may be allocated without storage, and their lifetime is different.
This here, is not about buffer storage, not WOW64 specific, not just even about buffers, and is about *names* instead. It introduces and will implement a set of int-to-int mapping tables which are self sufficient and isolated, and won't need to interact with any other logic. Whether we use PE-side object names or unix side object names, depending on which side of it we're on, does not really matter. I don't see any non-obvious protocol here, this logic, on the PE side, will very obviously manage the PE-side contexts lifetime and wglShareLists-specific PE-side context-sharing logic. It will use the unix side names for that, yes, but that's an arbitrary choice, and I think any other choice is just as arbitrary, and that managing PE-side context sharing rules on the unix side is not obvious. Mixing this with the WOW64 buffer wrapper logic with different lifetime rules, is also unlikely going to make things clearer. Regarding the non-obviousness I believe the outlier right now is actually the opengl32 module unix side, which awkwardly sits between opengl32 PE side and win32u / user drivers / host GL. Whatever it does should probably be moved either to the PE side, or to win32u, which is what I am generally aiming for. In any case I see no good reason to rewrite a several dozen of patches just because of some arbitrary choice, and if there's nothing to be said on the code itself, please lets move on with this. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/10870#note_141051