unsupported function problem - WinCE

[yoavrofe]

Hello all,

I'm trying to run a small program on both PPC and CE devices.
I am calling SHGetAutoRunPat h only when running on a PPC platform.
However, since this function depends on aygshell.dl, which doesn't
exist on the CE platform, the program does not run at all on the CE
platform.
if(lstrcmpi(lpC mdLine, _T("install")) == 0)
{
// Card has been inserted. We NEVER get here on a CE platform!

TCHAR szSDAutorunFull Path[MAX_PATH+1]; // Compact Flash path
SHGetAutoRunPat h(szSDAutorunFu llPath);
......
}

Is there a way to make the program run on both platforms without
recompiling it?

Thanks a lot,

Yoav.

[Victor Bazarov]

yoavrofe wrote:

I'm trying to run a small program on both PPC and CE devices.
I am calling SHGetAutoRunPat h only when running on a PPC platform.
However, since this function depends on aygshell.dl, which doesn't
exist on the CE platform, the program does not run at all on the CE
platform.
if(lstrcmpi(lpC mdLine, _T("install")) == 0)
{
// Card has been inserted. We NEVER get here on a CE platform!

TCHAR szSDAutorunFull Path[MAX_PATH+1]; // Compact Flash path
SHGetAutoRunPat h(szSDAutorunFu llPath);
.....
}

Is there a way to make the program run on both platforms without
recompiling it?

C++ language Standard defines the language so that the portability
requirement is satisfied on the *source code* level, not on the binary
level. No other guarantees exist from the platform point of view WRT
the executables you can produce from that code. Now, if your platform
chooses to give you some additional guarantees, e.g. that the executable
can run on two platforms if built with certain settings, then it's the
choice of the *platform*, not the language. IOW, you need to ask about
those things in the *platform* newsgroup, not the language newsgroup.

V
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask

[yoavrofe]

Thanks, Victor.

What I wanted to ask is if it's possible to declare the function only
when I intend to use it.

[Victor Bazarov]

yoavrofe wrote:

What I wanted to ask is if it's possible to declare the function only
when I intend to use it.

What's "intend to use it" mean. What would be the point of declaring it
if you don't intend to use it?

I am reaching here, but have you heard of "conditiona l compilation"? I
mean the #ifdef or #if blocks... It's not going to solve your "no
recompilation to run on the other OS" problem, though.

V
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask

[Jeff Schwab]

yoavrofe wrote:

Hello all,

I'm trying to run a small program on both PPC and CE devices.
I am calling SHGetAutoRunPat h only when running on a PPC platform.
However, since this function depends on aygshell.dl, which doesn't
exist on the CE platform, the program does not run at all on the CE
platform.
if(lstrcmpi(lpC mdLine, _T("install")) == 0)
{
// Card has been inserted. We NEVER get here on a CE platform!

TCHAR szSDAutorunFull Path[MAX_PATH+1]; // Compact Flash path
SHGetAutoRunPat h(szSDAutorunFu llPath);
.....
}

Is there a way to make the program run on both platforms without
recompiling it?

Define a semantically abstract interface to represent the underlying
platform. Implement this interface separately for each platform you
support, defining each such implementation in a separate source code module.

Your main routine, the client of the platform access modules, should
access the platform only through the abstract interface. Your build
system can then select the correct, platform-specific implementation to
link into your application for each build target. If you find there is
a lot of common code among the platform-specific modules, factor it into
a separate "platform support" module.

IOW, your driver routine probably shouldn't be calling something like
SHSomeHorridLoo kingFunctionNam e directly, anyway. Instead, it should be
calling platform.cardIn serted, where "platform" is of a type defined by
the build system. If you want to stick with the C-like coding style
above, you might just declare:

void platformCardIns erted();

Multiple compiled object modules can define platformCardIns erted, as
long as the build system links exactly one into your application for any
given build target.

Victor suggested #ifdef'ing out the platform-specific line. If it
really is just a very small amount of platform-specific code, that may
be the best thing to do; however: (1) it still requires target-specific
behavior in the build system, to pass -DPLATFORM=WHATE VER, and (2) as
Victor pointed out, it requires a separate compilation, rather than a
separate link, for each platform.

[Chris Becke]

First, this belongs more in comp.os.ms-windows.program mer.win32

Next, the function is declared:

BOOL WINAPI SHGetAutoRunPat h(LPTSTR pAutoRunPath);

Which is a normal C declration. So, to make life easy, first we make a function pointer typedef. How to do that is more c/c++ than win32. And we declare an instance of that new type and initialize it.

typedef BOOL(WINAPI* PFNSHGETAUTORUN PATH)(LPTSTR);
PFNSHGETAUTORUN PATH pSHGetAutoRunPa th = NULL;

Now, the win32 part. We load the function pointer from the relevent platform dll.

HMODULE hAygShell = LoadLibrary(TEX T("aygshell.dll "));
pSHGetAutoRunPa th = (PFNSHGETAUTORU NPATH) GetProcAddress( hAygShell,"SHGe tAutoRunPathW") ;

Now, you can test pSHGetAutoRunPa th to see if it was loaded or not before calling it with code similar to this:-

TCHAR szBuf[MAX_PATH]={0};
if(pSHGetAutoRu nPath) {
pSHGetAutoRunPa th(szBuf);
} else {
// fake it on platforms that dont have it.
}

One last note: "SHGetAutoRunPa thW" has the W on the end because most win32 functions exist in W or A suffix versions which are used when you build for Unicode or Ansi support. Because the platform in question might be unicode only, the W might not be necessary. If the GetProcAddress call fails on the platform it should succeed on, try the other variations.