   Include file problem, but not a n00b question )
  Hi,I'm "porting" a large C++/Pro*C application to VS2008. It currently uses imake to generate makefiles, which are then compiled using the old VC6 compiler. There are also makefiles for unix, as the app runs in an Unix environment during production. The windows makefiles are just to ease development which is mainly done on windows machines.The app uses Bea Tuxedo and WinSock at the same time. Problem is, winsock.h pulls in windows.h, in which in turn pulls in windef.h, which in turn pulls in winnt.h.Now, in winnt.h there is a enum defined like so:typedef enum _TRANSACTION_STATE {    TransactionStateNormal = 1,    TransactionStateIndoubt,    TransactionStateCommittedNotify,} TRANSACTION_STATE;Since the app uses tuxedo, it also includes tx.h, which contains a typedef with the exact same name, TRANSACTION_STATE......and so I get a nasty error when compiling. I've looked at the makefiles but so far I haven't found anything that I think could resolve this. And yet it compiles when I use them :)Before your ask, sorry, I can't post the makefiles because of legal issues. This app/code is very sensitive material for a large corporation and I can't let *any* part of it out to the public. I realize this makes anyone helping me all the more difficult, but it's not an option.That said, does anyone know a solution to the problem? Since it compiles with the make files, there has to be a way to make it compile using Visual Studio .sln / .vcproj-files. Any ideas would be *greatly* appreciated :)Thanks in advance,SimonP.S. Please refrain from posts of the type: "Why are you using technology X? Why not use Y, it's much more modern" etc. This is an old, thoroughly tested and sensitive codebase, which will continue to be run for many years to come (i.e. not game code). Using different technologies / rewriting the code is not an option. The move to Visual Studio is simply to ease development of the existing code, not an opportunity to make large modfications to the code.    
  IIRC, TRANSACTION_STATE is used with TRANSACTION_BASIC_INFORMATION, which was introduced with Windows Vista. It could be that VC6 is compiling it just because its platform SDK headers predate Vista.   ;  And that is why people should respect the rule that identifiers with a leading underscore are reserved for use by compiler vendors.Sorry, that doesn't help you much, I know. I'll think some more about this, though, to try and come up with helpful suggestions.P.S. Nevermind, I noticed that my comment doesn't apply at all, since the actual collision occurs between TRANSACTION_STATE and TRANSACTION_STATE without leading underscores.   ;  Do the modules that need to pull in winnt.h also have to #include tx.h? Try reducing the number of #include directives in your header files by using forward declarations where ever possible. Maybe you can avoid having to #include winnt.h (or any headers that directly or indirectly #include winnt.h) AND tx.h in the same compilation unit.   ;  Oh yeah, one more thing. Before you #include any windows headers, define the following:#define WIN32_LEAN_AND_MEAN#define EXTRA_LEANThat way you can cut down on a lot of unnecessary stuff that would otherwise get #included.   ;  Thanks for your fast replies! I'm at home right now, but when I get to work I'll try your suggestions.@SiCrane: I still have the VC6 headers/libs installed, so I will try to simply changing the paths to them. Hopefully this will solve the problem! It never occurred to me that MS might have changed the headers... :)@Red Ant: Unfortunately the module needs both tx.h and winsock.h (and winsock.h in turn implicitly includes winnt.h) right now. To separate the two I would need to separate the networking functionality from the tuxedo calls, which would mean a code rewrite.I will try the other tip you gave me about the #defines though!Thanks again for both your suggestions! :)/Simon   ;  Hi,just an update if anyone else has this problem: setting VS2008 to use the old compiler/options/headers/libs solved the problem.Too bad we can't use the new stuff, but at least now it compiles, and we can still use the nice IDE of VS2008.I guess this is exactly the kind of thing namespaces are for ;)Thanks again!/Simon