OK, I see now what the main problem is: The list of options in WinBoard contains not only pointers to appData fields (for back-end options), but also many pointers directly to front-end variables. In particular there are lots of window-coordinate options, and even in WinBoard there are two different systems for storing them: an obsolete way as simple variables, e.g. commentX, commentY, commentW, commentH, or a modern way, which can be subject to the -stickyWindows option (I guess this is called "docking"), where they are stored in fields of a WindowPlacement struct.
A lot of code in the SaveSettings routine is dedicated to obtaining the window coordinates, i.e. very front-end, and becase of the different systems in use it is difficult to move that code to the front-ed as a callable function. Of course it would be possible to split the option list in a front-end and a back-end part, and let ParseArgs work on both parts separately, while spliting SaveSettings in two parts as well. In the end we will want similar front-end options in XBoard and WinBoard, though, in particular all the window coordinates. I guess the best approach would be to first do a lot of code refactoring in winboard.c, to get better front-end and back-end separation of the option handling. In particular, all windows should be adressible through a #defined (in common.h?) numeric ID which is kown to the back-end, and all platform-ependent handles to the windows (which now are simple variables with names like HWND engineOutputDialog in WinBoard and Widget engineOutputShell in Xboard) should then be grouped into an array indexed by this ID. All simple coordinate variables should then be grouped in a corresponding (back-end) array of WindowPlacement structs. The only front-end part would then be a routine that fills the WindowPlacement struct of a window with given ID, and the rest could all be back-end. Another problem area seems to be the handling of fonts.
