Windows porting problems
Moderator: Ras
-
- Posts: 1922
- Joined: Thu Mar 09, 2006 12:51 am
- Location: Earth
Windows porting problems
As I'm trying to get around to making my program fully Windows-compatible, I'm running into problems. I've compiled it fine in the past on a computer that didn't have the SDK installed on it, i.e. there isn't a Windows.h. This just meant I couldn't use some functions I needed for input and SMP. But now that I've tried again with the SDK to use these functions, I realize that the Windows.h file clashes with many of my constant names. First, there is the BOOL, but that is not hard to change. But then there are things like TESTING, which I use in an enum. I'd rather not have to change this constant name throughout my whole program. Is there any technique that you know of to help a port to windows? Perhaps only including more specific header files?
-
- Posts: 12777
- Joined: Wed Mar 08, 2006 8:57 pm
- Location: Redmond, WA USA
Re: Windows porting problems
Separate the Windows specific routines into their own files.
Include only the API to the windows specific routines as a header to your chess program.
Include only the API to the windows specific routines as a header to your chess program.
-
- Posts: 1922
- Joined: Thu Mar 09, 2006 12:51 am
- Location: Earth
Re: Windows porting problems
Hmmm... Probably not possible, and rather ugly too. I wonder if I could somehow separate the parts of the program that need it though...Dann Corbit wrote:Separate the Windows specific routines into their own files.
What do you mean by this? Like usingInclude only the API to the windows specific routines as a header to your chess program.
Code: Select all
extern LPVOID SomeStupidWindowsFunctionWithLongName(HANDLE *hAndle, DWORD dwUselessParameter...);
I hope my bias isn't showing through that example...

-
- Posts: 2251
- Joined: Wed Mar 08, 2006 8:47 pm
- Location: Hattingen, Germany
Re: Windows porting problems
I guess Dann means to make your interfaces (h-files) windows (os) independent and only include windows.h in one c(pp) file with all os-dependent stuff implemented. Don't be afraid to rename some symbols. You may use namespaces inside your program, and you may tryZach Wegner wrote:Hmmm... Probably not possible, and rather ugly too. I wonder if I could somehow separate the parts of the program that need it though...Dann Corbit wrote:Separate the Windows specific routines into their own files.What do you mean by this? Like usingInclude only the API to the windows specific routines as a header to your chess program.for each function I use?Code: Select all
extern LPVOID SomeStupidWindowsFunctionWithLongName(HANDLE *hAndle, DWORD dwUselessParameter...);
I hope my bias isn't showing through that example...
#define WIN32_LEAN_AND_MEAN
before including windows.h
Gerd
-
- Posts: 12777
- Joined: Wed Mar 08, 2006 8:57 pm
- Location: Redmond, WA USA
Re: Windows porting problems
What I mean is like this:
Probably one or two functions are operating system specific.
Natural common examples are keyboard input and timing functions.
All the other functions in the chess program do not care at all about the operating system.
So take the functions that need headers that are not owned by ANSI/ISO C and put them in a separate translation unit.
Examine (for instance) the files of Dr. Hyatt's chess engine Crafty. You will find a single C file that contains:
#include <windows.h>
and the name of that file is utility.c
All other C files do not contain Windows specific headers because they are not needed. As you can see, this file from crafty is designed to run against a large number of client platforms:
This is a very good idea in general. We do it at CONNX.COM all the time since our tools run on everything under the sun (including the sun).
Probably one or two functions are operating system specific.
Natural common examples are keyboard input and timing functions.
All the other functions in the chess program do not care at all about the operating system.
So take the functions that need headers that are not owned by ANSI/ISO C and put them in a separate translation unit.
Examine (for instance) the files of Dr. Hyatt's chess engine Crafty. You will find a single C file that contains:
#include <windows.h>
and the name of that file is utility.c
All other C files do not contain Windows specific headers because they are not needed. As you can see, this file from crafty is designed to run against a large number of client platforms:
Code: Select all
#include <stdio.h>
#include <stdlib.h>
#include <stdarg.h>
#include <string.h>
#include <errno.h>
#include <ctype.h>
#include "chess.h"
#include "data.h"
#if !defined(AMIGA)
# include <limits.h>
#endif
#if defined(OS2)
# include <sys/select.h>
#endif
#if defined(NT_i386)
# include <windows.h>
# include <winbase.h>
# include <wincon.h>
# include <io.h>
# include <time.h>
#else
# include <sys/times.h>
# include <sys/time.h>
#endif
#if defined(UNIX)
# include <unistd.h>
# include <sys/types.h>
# if !defined(LINUX) && !defined(ALPHA) && !defined(HP) && !defined(CRAY1) && \
!defined(FreeBSD) && !defined(NetBSD) && !defined(__EMX__)
# if defined(AIX)
# include <sys/termio.h>
# include <sys/select.h>
# else
# if defined(NEXT)
# include <bsd/termios.h>
# include <sys/ioctl.h>
# else
# include <sys/filio.h>
# endif
# endif
# if !defined(NEXT)
# include <stropts.h>
# endif
# include <sys/conf.h>
# else
# include <sys/ioctl.h>
# endif
# include <signal.h>
# include <sys/wait.h>
#endif
#if defined(UNIX)
# include <sys/ipc.h>
# include <sys/shm.h>
#endif
#if defined(__EMX__)
# define INCL_DOS
# define INCL_KBD
# include <os2.h>
#endif