In protocol.def, the get_startup_info request declares two VARARGS as replies. Unless I've mistaken, replies are limited to one VARARG that the server call writes into preallocated data, right?
That leads me to my next question: I'm currently working on moving menus into the server (see http://silenceisdefeat.org/~tkho/seas/wine/patches/menu-0622-3/ for a series of patches that moves most menu data into the server. Most logic is still on the client, but it's still surprisingly snappy.) If you look at http://silenceisdefeat.org/~tkho/seas/wine/patches/menu-0622-3/10-server-mii, my problem is that I don't know the size of the data that the server is going to return and my current hack is to set a hard upper limit.
I can think of two ways to tackle this:
1. Do a server call before hand to request the size of the data to be returned. This has the overhead of the additional call, but doesn't increase the complexity of the server itself.
2. Instead of preallocating memory for the variable reply, have the request mechanism allocate it (like it does on the server end for variable sized data in the request). This also adds complexity as the reply would be callee-allocated, caller-freed (or perhaps we could take advantage of SERVER_END_REQ?). However, it seems kind of natural to have the request process parallel the reply process.
Is there another alterative? Any comments on which approach is better?
Thomas Kho