Conflicting typedef with winnt.h, windef.h and winbase.h

[Lathe_Biosas]

Hi

While compiling my application that needs "windows.h" there are some
typedef redefinition errors

redefinition at winnt.h( line 207) typedef void *HANDLE
redefinition at windef.h( line 143) typedef unsigned char BYTE
redefinition at windef.h( line 141) typedef unsigned long DWORD

#define INVALID_HANDLE_VALUE -1 redefinition at winbase.h(55) #define
INVALID_HANDLE_VALUE (HANDLE)-1

The DLL that links to my application needs the following typedefs at
the moment declared at my_include.h
As stated in User Manual --> My Definition (working and handling data
perfect but without windows.h)

HANDLE: An opaque 32-bit integer --> typedef int HANDLE;
BYTE: A 8-bit unsigned integer --> typedef unsigned int BYTE;
DWORD: A 32-bit unsigned integer --> typedef unsigned int DWORD;
LPBYTE: A 32 bit flat pointer to a variable of type BYTE --> typedef
BYTE * LPBYTE;
LPDWORD: A 32 bit flat pointer to a variable of type DWORD --> typedef
DWORD * LPDWORD;

#define INVALID_HANDLE_VALUE -1

Is it possible to make my typedefs compatible with the ones of winnt.h,

windef.h and winbase.h and still manage the data as stated in the DLL
User Manual?

Any help would be kindly appreciated
Best Regards

[Ulrich Eckhardt]

Lathe_Biosas wrote:

While compiling my application that needs "windows.h" there are some
typedef redefinition errors

redefinition at winnt.h( line 207) typedef void *HANDLE
redefinition at windef.h( line 143) typedef unsigned char BYTE
redefinition at windef.h( line 141) typedef unsigned long DWORD

#define INVALID_HANDLE_VALUE -1 redefinition at winbase.h(55) #define
INVALID_HANDLE_VALUE (HANDLE)-1

Not sure what you're saying, but you're not saying it's an internal
conflict in the supplied headers, right?
The DLL that links to my application needs the following typedefs at
the moment declared at my_include.h
As stated in User Manual --> My Definition (working and handling data
perfect but without windows.h)

HANDLE: An opaque 32-bit integer --> typedef int HANDLE;
BYTE: A 8-bit unsigned integer --> typedef unsigned int BYTE;
DWORD: A 32-bit unsigned integer --> typedef unsigned int DWORD;
LPBYTE: A 32 bit flat pointer to a variable of type BYTE --> typedef
BYTE * LPBYTE;
LPDWORD: A 32 bit flat pointer to a variable of type DWORD --> typedef
DWORD * LPDWORD;

#define INVALID_HANDLE_VALUE -1
How about you put all your stuff into a common namespace by adding a common
prefix? Other than that, for explicitly sized types, use stdint.h and
uint8_t or int32_t instead of inventing you own stuff that is confusing
(unsigned int = 8bit?) or even wrong (a word is not always 16 bit).

BTW: it's a good idea to reserve ALL_UPPERCASE for macros - that way you
can immediately spot them.
Is it possible to make my typedefs compatible with the ones of winnt.h,
windef.h and winbase.h and still manage the data as stated in the DLL
User Manual?

Change the typedefs, simple as that. In that aspect, your headers are as
broken as the win32 ones, but changing yours will probably be easier.

Uli

[Lathe_Biosas]

Ulrich Eckhardt wrote:

Not sure what you're saying, but you're not saying it's an internal
conflict in the supplied headers, right?

YES

The DLL that links to my application needs the following typedefs at
the moment declared at my_include.h
As stated in User Manual --> My Definition (working and handling data
perfect but without windows.h)

HANDLE: An opaque 32-bit integer --> typedef int HANDLE;
BYTE: A 8-bit unsigned integer --> typedef unsigned int BYTE;
DWORD: A 32-bit unsigned integer --> typedef unsigned int DWORD;
LPBYTE: A 32 bit flat pointer to a variable of type BYTE --> typedef
BYTE * LPBYTE;
LPDWORD: A 32 bit flat pointer to a variable of type DWORD --> typedef
DWORD * LPDWORD;

#define INVALID_HANDLE_VALUE -1

How about you put all your stuff into a common namespace by adding a common
prefix? Other than that, for explicitly sized types, use stdint.h and
uint8_t or int32_t instead of inventing you own stuff that is confusing
(unsigned int = 8bit?) or even wrong (a word is not always 16 bit).

I didn't invented my own stuff (typedefs), what you can read on my post
is cited from the DDL Programming Functions Users Manual. (As stated in
User Manual) They define a BYTE as a 8 bit unsigned integer, why?,
unfortunatelly I don't know that.

Is it possible to make my typedefs compatible with the ones of winnt.h,
windef.h and winbase.h and still manage the data as stated in the DLL
User Manual?

Change the typedefs, simple as that. In that aspect, your headers are as
broken as the win32 ones, but changing yours will probably be easier.

As I'm a beginner with programming I thought there was an elegant
solution to make
interact the typedefs of windows.h and the typedefs of header file
provided. (i.e. Some kind of typecast)

What I did for the moment was to _invent_ a new header file
(modification of the one that was provided), removed all the
conflicting typedefs and modified the existing extern fuctions with C
data types, i.e. (int instead of HANDLE).

It compiled with out problems, I will check now the variables are
sending the right values. As for now the HANDLE handles ok.

Thank you for your answer
Kind Regards

[Flash Gordon]

Lathe_Biosas wrote:

Ulrich Eckhardt wrote:

Not sure what you're saying, but you're not saying it's an internal
conflict in the supplied headers, right?
YES

Most likely including a header you are not meant to include directly.

The DLL that links to my application needs the following typedefs at
the moment declared at my_include.h
As stated in User Manual --> My Definition (working and handling data
perfect but without windows.h)

HANDLE: An opaque 32-bit integer --> typedef int HANDLE;

<snip>
I didn't invented my own stuff (typedefs), what you can read on my post
is cited from the DDL Programming Functions Users Manual. (As stated in
User Manual) They define a BYTE as a 8 bit unsigned integer, why?,
unfortunatelly I don't know that.

All this is highly Windows specific, so please take it to a Windows
programming group. Here we deal with standard C, not the extension
provided by Windows, Posix, Linux etc.
--
Flash Gordon
Living in interesting times.
Although my email address says spam, it is real and I read it.

[Lathe_Biosas]

Hi thanks for you answer, I will go to the Windows specific group

By the way, what is the meaning of <snip> ?

Regards

[Lathe_Biosas]

>Most likely including a header you are not meant to include directly.
mmm... Maybe....

Hi thanks for you answer, I will go to the Windows specific group

By the way, what is the meaning of <snip> ?

Regards

[Flash Gordon]

Lathe_Biosas wrote:

<snip>

By the way, what is the meaning of <snip> ?

It is used to indicate where you have snipped some of the text from the
message you are replying to.
--
Flash Gordon
Living in interesting times.
Although my email address says spam, it is real and I read it.

[Alan Balmer]

On 1 Sep 2005 14:01:17 -0700, "Lathe_Biosas"
<la**********@hotmail.com> wrote:

Most likely including a header you are not meant to include directly.

mmm... Maybe....

Hi thanks for you answer, I will go to the Windows specific group

By the way, what is the meaning of <snip> ?

Regards

It indicates that material not relevant to the reply has been edited
out (snipped).
--
Al Balmer
Balmer Consulting
re************************@att.net

[Joe Wright]

Lathe_Biosas wrote:

Most likely including a header you are not meant to include directly.

mmm... Maybe....

Hi thanks for you answer, I will go to the Windows specific group

By the way, what is the meaning of <snip> ?

Regards

Snipping is what you do with scissors.

--
Joe Wright
"Everything should be made as simple as possible, but not simpler."
--- Albert Einstein ---