[lnkForumImage]
TotalShareware - Download Free Software
Confronta i prezzi di migliaia di prodotti.
Asp Forum
 Home | Login | Register | Search 


 

Forums >

comp.lang.c++

unsupported function problem - WinCE

yoavrofe

10/2/2008 2:52:00 PM

Hello all,

I'm trying to run a small program on both PPC and CE devices.
I am calling SHGetAutoRunPath 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(lpCmdLine, _T("install")) == 0)
{
// Card has been inserted. We NEVER get here on a CE platform!

TCHAR szSDAutorunFullPath[MAX_PATH+1]; // Compact Flash path
SHGetAutoRunPath(szSDAutorunFullPath);
......
}

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

Thanks a lot,

Yoav.
5 Answers

Victor Bazarov

10/2/2008 6:03:00 PM

0

yoavrofe wrote:
> I'm trying to run a small program on both PPC and CE devices.
> I am calling SHGetAutoRunPath 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(lpCmdLine, _T("install")) == 0)
> {
> // Card has been inserted. We NEVER get here on a CE platform!
>
> TCHAR szSDAutorunFullPath[MAX_PATH+1]; // Compact Flash path
> SHGetAutoRunPath(szSDAutorunFullPath);
> .....
> }
>
> 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

10/2/2008 9:03:00 PM

0

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

10/2/2008 9:12:00 PM

0

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 "conditional 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

10/2/2008 9:47:00 PM

0

yoavrofe wrote:
> Hello all,
>
> I'm trying to run a small program on both PPC and CE devices.
> I am calling SHGetAutoRunPath 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(lpCmdLine, _T("install")) == 0)
> {
> // Card has been inserted. We NEVER get here on a CE platform!
>
> TCHAR szSDAutorunFullPath[MAX_PATH+1]; // Compact Flash path
> SHGetAutoRunPath(szSDAutorunFullPath);
> .....
> }
>
> 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
SHSomeHorridLookingFunctionName directly, anyway. Instead, it should be
calling platform.cardInserted, 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 platformCardInserted();

Multiple compiled object modules can define platformCardInserted, 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=WHATEVER, and (2) as
Victor pointed out, it requires a separate compilation, rather than a
separate link, for each platform.

Chris Becke

10/3/2008 10:15:00 AM

0

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

Next, the function is declared:

BOOL WINAPI SHGetAutoRunPath(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* PFNSHGETAUTORUNPATH)(LPTSTR);
PFNSHGETAUTORUNPATH pSHGetAutoRunPath = NULL;

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

HMODULE hAygShell = LoadLibrary(TEXT("aygshell.dll"));
pSHGetAutoRunPath = (PFNSHGETAUTORUNPATH) GetProcAddress(hAygShell,"SHGetAutoRunPathW");

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

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

One last note: "SHGetAutoRunPathW" 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.