Which ones? There should only be a handful of functions needed for WSI interop with win32u, and it could be wgl-like, but perhaps more likely a custom interface defined in opengl_driver.h, like is already the case.
wglCreateContext or wglCreateContextAttribsARB(), wglDeleteContext(), wglGetCurrentContext(), wglGetCurrentDC(), wglMakeCurrent(), wglSwapBuffers(), wglSwapIntervalEXT(). That's the usual context manipulation and presentation; I can't really guess whether any of that is in danger because I don't have a full idea of what you feel belongs on the PE side. I wouldn't have said anything does. wglShareLists(), which I guess we can omit in that case since it won't do anything. wglGetPixelFormat(), which I guess can be avoided if we make the pixel format completely virtualized.
Also fwiw, my intention is to also try splitting opengl32 into a runtime and an ICD module, so that we can then implement an alternative pure PE zink ICD over PE vulkan.
Why?
That means various wgl functions are meant to be PE-side only, and the ICD that bridges host GL through the unixlib -and the win32u interface with it- would then rather follow the ICD internal calls instead for WSI.
Why does it mean that? If Zink implements WGL it should implement all of it; I don't see why any of it would be not Zink's responsibility? -- https://gitlab.winehq.org/wine/wine/-/merge_requests/11161#note_143294