Want to protect your cyber security and still get fast solutions? Ask a secure question today.Go Premium

x
  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 301
  • Last Modified:

Using non-Unicode compiled dll with a unicode program

We have a dll compiled in unicode having for example a follwing function header:

void foo(TCHAR* pChar);

the side using the dll 'sees' this as an unsigned short while in actuality it was compiled in the dll as a char. As a result the linker throws an 'unresolved external' cuz it can't find the implementation it's looking for.

We tried hacking this by doing something like the follwing

#ifdef _UNICODE
#undef _UNICODE
void foo(TCHAR* pChar);
#define _UNICODE

so that the app side will think it's a char too, but apperently the TCHAR is evaluated before this (Precompiled headers??) so it still thinks it's an unsigned short. What can we do about this?

Just so I'm clear, we want to be able to send a char* to foo().

cheers,
RL
0
RandomLogic
Asked:
RandomLogic
1 Solution
 
jkrCommented:
>>we want to be able to send a char* to foo().

Then, you'll need to use a wrapper for that function, e.g.

void fooA(char* pChar) {

wchar_t* pwsz = new wchar_t [strlen(pChar) + 1];

wsprintfW ( pwsz, L"%S", psz);

foo(pwsz); // call with UNICODE string

delete [] pwsz;
}
0
 
waysideCommented:
>We have a dll compiled in unicode having for example a follwing function header:...
> ...actuality it was compiled in the dll as a char.
> Just so I'm clear, we want to be able to send a char* to foo().

Well, you contradict yourself because you say the dll is compiled as unicode but you need to pass the dll function a char *.

So I am assuming your calling program is compiled as unicode and the dll is not.

Your hack fails because tchar.h will have already been included by the time you undefine _UNICODE, so the value set for TCHAR is already established. You'd have to undefine _UNICODE before tchar.h is included, this will probably break lots of other stuff in your code.

I see two possible solutions:

1) change the header file to define the functions as taking char *, thus removing the ambiguity

2) have a separate header file with the correct type, one for the dll and one for the calling program

TCHAR itself is a typedef, I don't think you can change it or you get compile errors. So you can't do much with that.

If you want to have only one header file, you could do something heinous like

#ifdef COMPILING_IN_DLL
void foo(TCHAR *pChar);
#else
void foo(char *pChar);
#endif

at least this way the definitions are all in one place, you'd be less likely to miss something if you needed to change the definition.

I think the best bet is #1 above; if you really need a char *, why use TCHAR?
0

Featured Post

[Webinar] Database Backup and Recovery

Does your company store data on premises, off site, in the cloud, or a combination of these? If you answered “yes”, you need a data backup recovery plan that fits each and every platform. Watch now as as Percona teaches us how to build agile data backup recovery plan.

Tackle projects and never again get stuck behind a technical roadblock.
Join Now