WindowsProgramming

Webs: Faemalia -:- Greatprawn -:- Playground -:- Technical -:- Tweak Technical Web Sections: Register -:- Users -:- Changes -:- Index -:- Search -:- Statistics

To avoid tendencies of 'All-the-world's-Unix', here's some notes on things to remember to keep Dia compilable under Windows.

Notes on global definitions by Hans Breuer:

Adding 'extern' to headers is asking for trouble. With simple (not dynamic) variables it can be fixed by DIAVAR; not that I would consider global variables good prograamming style at all.

• If it's a variable -> use DIAVAR
• If it's a function -> add it to libdia.def
• If it's not defined in libdia -> rethink implementation to keep the design clean and cross platform. Only exception is app/ exporting functions, there is app/dia.def to export them to be used by 'extended' plug-ins...

Some notes by Cyrille and Hans:

1. Stick to the published glib/gtk APIs
2. Never assume that the path separator is /, use the glib macros
3. when in doubt, assume the linker is dumber than your worst dreams.
4. avoid anything else than pure C compilation and linking (e.g don't depend on sed pre-processing, or a large python post-processing)
5. Remember that configure is not used on Win32; rather, there is a static config.h file. If what you do causes new tests to be added to configure.in, you have to provide the outcome on the win32 platform into the static config.h file.
6. Anything that touches Postscript and printing has chances to be different.
7. Beware anything approaching advanced interaction with the window manager -- the default unreplaceable window manager in Windows won't do what you expect it to (or more politely, the flexibility X offers and gtk thinly wraps doesn't map very well to the features offered by Win32).
8. This list is likely wrong and/or incomplete (especially as there are efforts to go to MinGW^?, which is a different toolchain compared to MSVC)
9. Look at the intersection of contributors to gtk-win32 and dia.
10. if you expect files to be binary read tell the open function to do it. (O_BINARY or "rb"). There is the ugly Oxa -> 0xd Oxa mapping otherwise.
11. Don't rely on a specific Pango backends facility - here PangoFT2^?, instead of PangoWin32^? if ever possible. It's not hard to implement the same stuff within win32 as done by FT2, but it appears almost impossible to get such patches accepted in Pango.
12. If you are forced to do non portable stuff, just do it. Don't try to guess how to port it, but instead let it break at compie time. If the *nix codes intention isn't obvious some documentation is much more helpful than hidden or halfway ported code. IMO it is much simpler to fix when compiling on win32 fails instead of searching for (longtime) unnoticed portability problems at runtime. Even better yet, use #ifdefs and #errors in an explicit way. When testing for a potentially non-portable situation, avoid testing for the platform but test for features instead (where applicable -- for stuff which depends on the GDI, it'd be quite ridiculous to define HAVE_CREATEDC, HAVE_RELEASEDC, HAVE_SELECTOBJECT et al.)
13. Beware of gccism like switch (x) {defaut : } does compile with gcc but msvc wants a statement even if it's an empty one : ; in fact, beware of any gccisms at all. I don't see a compelling reason why dia would require gcc intrinsics or __attribute__(I don't give a damn about portability) hell.
14. keep your alloc/dealloc pairs in sync g_new,g_malloc->g_free; malloc/free; xmlGetProp/xmlFree not always maps to the same runtime functions (this is true for *nix builds, too.)
15. don't unconditionally include non standard headers, e.g. unistd.h. If there is some HAVE_UNISTD_H or similar defined there is a reason for it.
16. Declare all your functions befre using them. Note : this is not a deficiency of the msvc compiler but some enforced coding style through pragmas (-FImsvc_recommended_pragmas.h)hell. avoid c89 constructs until Hans says that the primary Win32 compiler is happy with them.
17. Don't assume hardcoded pathes - win32 gtk programs can be installed anywhere without recompiling. There is some support in GLib to do this a well as in Dia, see lib/dia_dirs.[hc]
18. Try to avoid global variables, especially accross dynamic library boundaries. They are almost always bad coding style and need special handling on win32.

If what you are doing is confined to new object types, or straight GUI work, and you don't do much file or network I/O and you do it carefully, your odds are good out of the box.

Point well taken for non-win32, non-ELF platforms (Solaris springs to mind):

1. Do not assume that if liba requires libb and libb requires libd, you get libd into liba by just pulling -lb. You have to add -ld as well.

we get about a report or two per release, due to ELF-induced linker sloppiness.

-- LarsClausen - 24 Sep 2003