Re: VS2005 compatibility

As I said a number of messages back, when I take the source code that you
posted as part of your message and build it into a project that I create
using the New Project Wizard, it works fine on my Pocket PC. You are
clearly doing something wrong in your project or your SDK is broken. It's
not a problem with the environment or some setting that you need to change
from the default (since, other than the entry point, I changed no defaults).
I suppose that you could install the Pocket PC 2005 SDK and try the emulator
or a real PPC2005 device, to try to put the blame on your SDK. I'm afraid
that you're on your own for the next week or two, as I'll be out of the
country. Maybe someone else has some ideas...

Paul T.

"Long" <Long@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:EF376E14-1EA3-4179-80E7-C1538DF09EDD@xxxxxxxxxxxxxxxx
Thanks for your info, Paul. I have other thing interesting that might be
a
clue for you. If I put the line "CReg reg;" outside the _tmain()
function, a
global variable, the program can run. So it seems a memory management
problem. I know the Link have the Heap and Stack memory settings. But no
matter what I set those params, it doesn't help if the "CReg reg;" is put
inside the _tmain() function. What do you think?
"Paul G. Tobey [eMVP]" wrote:

It could be:

1. You are trying to load a module into user space that is a kernel
module
(not the problem here).

2. You are trying to access an exported API function in coredll.dll that
isn't in your version of coredll.dll. This would indicate a mismatch
between the SDK and the actual items built into the OS.

3. The EXE could really be bad. I don't know how you would have
accomplished this, but you might have used the wrong linker, the wrong
linker settings, or something of that nature.

4. The operating system might be set up to validate all loads before they
are allowed to occur and it might have found your EXE not-allowed because
it's not signed or whatever.

5. It could be compiled for the wrong CPU type. Based on your
description
of the target device and what I see in the EXE, I don't think this is the
problem.

6. There could be a problem reading the contents of the EXE file. This
might happen, I suppose, if it were on a storage device and the file
allocation table or whatever was bad or there was a bad sector.

7. I suppose that this might happen if you tried to run a DLL as a
program.

If it were me, I'd start over with a new program, make sure I was
targeting
the right SDK. Then, I'd use the code in the main module, running from
WinMain(), rather than fooling with tmain(), etc. and adding the code for
the registry class directly to the same .cpp file. Since it's
self-contained, that eliminates any problem include files, which might
have
references to libraries to be linked, etc. Since that's what I did here
with your code, targeting PPC2003, and it worked, I think that will work
for
you, also. Then you just have to check where in the *code* the problem
came
from, which is a much smaller search space than code+configuration
settings.

Paul T.

"Paul G. Tobey [eMVP]" <p space tobey no spam AT no instrument no spam
DOT
com> wrote in message news:e$encTU0GHA.4976@xxxxxxxxxxxxxxxxxxxxxxx
Yes, the application might have the wrong setting for the OS version
(although I think that this might have a customized error), the wrong
setting for the Windows subsystem, the wrong processor selected. There
isn't a long list, but there are a few items. I'm looking to see if I
can
figure out what the list is, exactly. Try putting the registry class
in
the same file as the tmain() function.

Paul T.

"Long" <Long@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:3A0B9671-30B2-4855-90F3-8E9CA6030AE1@xxxxxxxxxxxxxxxx
Hi Paul, Thanks for your helping. Yes, I'm using CE 5.0. Would that
message
be a generic one? I mean that other errors could also generate this
message?

"Paul G. Tobey [eMVP]" wrote:

And the device that you are targeting is running Windows CE 5.0? I
don't
see any problems with the header or the imports. The header is
marked
for
THUMB processor, Windows CE 5.0, GUI, all standard stuff for
targeting
Windows CE ARM-based devices running 5.0 or later.

Paul T.

"Long Deng" <langdeng@xxxxxxxxxxx> wrote in message
news:OcfJaVT0GHA.3440@xxxxxxxxxxxxxxxxxxxxxxx
Hi Paul,

Attached is the ZIP of the problem EXE. Thank you.

"Paul G. Tobey [eMVP]" <p space tobey no spam AT no instrument no
spam
DOT
com> wrote in message
news:%23956p%23S0GHA.4408@xxxxxxxxxxxxxxxxxxxxxxx
If you're using a Web-based interface, I can't help you with
attachments.
I'm using a real newsreader which has no problems with it.

You say "I can download the program to the target device to run
it".
So,
what happens if you try to run the problem program in the
debugger?

Paul T.

"Long" <Long@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:DD9213CA-BF6A-47E2-BA60-2EA3BC140A69@xxxxxxxxxxxxxxxx
I don't think I was using an emulator, because I can download the
program
to
the target device to run it (first example) or copy the program
manually
to
the device and run it.

As for the Workspace I mentioned, actually the two example are
using
the
same project "workspace". I just modified the _tmain() function
to
call
APIs
or use the CReg. So the project settings should be the same.
They
are
all
compiled successfully. The only differece is one can run and the
other
not.
I don't know how to attached the exe here. I cannot find any
other
options.

"Paul G. Tobey [eMVP]" wrote:

2. In this wizard, you adjusted things so that the targets
listed
are
just
your specific device?

Are you sure you're not building for the Colibri emulator? That
would
be
an
x86 EXE, not ARM, as needed for the real device. Project
settings
are
not
attached to a workspace; they are part of the project. If the
project
was
not generated as a Smart Device application, you've found your
problem.

You can attach the EXE itself and I'll see what the headers look
like,
but
the system works well, generally, so you're doing something way
off
the
track...

Paul T.

"Long" <Long@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:5EDFDEB1-4B4D-4869-A0D4-02278F09E4A7@xxxxxxxxxxxxxxxx
I must make some mistakes when typing the second examples, i.e.
ValueDW(),
instead of copying and pasteing the code. I think I did the
same
as
you
did
except my program cannot run. This is what I did.

1. Create a Smart Device project.
2. Remove the default device and select my device: Colibri.
3 Select Console Application. ATL, MFC and Empty project are
unchcked.
4. Then finish thw wizard. Everything is in default settings.
5. Then type in my code, compile and run with or without
debugging.

These projects do not need additional libraries. But I don't
know
what
default libs they use. So I don't think I change them.
Besides
I
use
the
same workspace and settings to compile the two examples, one
can
run
and
the
other doesn't. If that is not a problem from VS2005, would
that
comes
from
BSP or its SDK?

"Paul G. Tobey [eMVP]" wrote:

And a thought arises. What libraries are you linking with?
Did
you
change
anything from the default generated by the VS2005 new project
wizard
to
target Smart Devices?

Paul T.

"Long" <Long@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:491D9629-7A31-4251-AA3F-DCF47D434F4A@xxxxxxxxxxxxxxxx
Thanks Paul,

Here is the code without problems.

#include "stdafx.h"
#include <windows.h>
#include <commctrl.h>

int _tmain(int argc, _TCHAR* argv[])
{
wprintf(L"Starting...\n");

HKEY m_hKey;
int m_Index;
LPBYTE m_lpbValue; // last value read, if any

//TCHAR szValue[MAX_PATH];
DWORD ret = RegOpenKeyEx(HKEY_LOCAL_MACHINE, L"Comm", 0,
KEY_READ,
&m_hKey);
DWORD dwValue = 1;
DWORD dwLen = sizeof(DWORD);
ret = RegQueryValueEx(m_hKey, L"BootCount", NULL, NULL,
(LPBYTE)&dwValue,
&dwLen);

ret = RegSetValueEx(m_hKey, L"Test", 0, REG_DWORD,
(LPBYTE)&dwValue,
sizeof(DWORD));

ret = RegCloseKey(m_hKey);

ret = RegFlushKey(HKEY_LOCAL_MACHINE);

Sleep(1000);
wprintf(L"Exiting...\n");

return 0;
}

Here is the code that can be compliled successfully, but
not
run.

//CReg class RegHelper.h
#pragma once
/////////////////////////////////////////////////////////////////////////////
// CReg: Registry helper class
/////////////////////////////////////////////////////////////////////////////
#define MyFree(p) { if(p) LocalFree(p); }

class CReg
{
private:
HKEY m_hKey;
int m_Index;
LPBYTE m_lpbValue; // last value read, if any

public:
BOOL Create(HKEY hkRoot, LPCTSTR pszKey) {
DWORD dwDisp;
return ERROR_SUCCESS==RegCreateKeyEx(hkRoot, pszKey, 0,
NULL,
REG_OPTION_NON_VOLATILE, KEY_ALL_ACCESS, NULL, &m_hKey,
&dwDisp);
}

BOOL Open(HKEY hkRoot, LPCTSTR pszKey, REGSAM sam=KEY_READ)
{
return ERROR_SUCCESS==RegOpenKeyEx(hkRoot, pszKey, 0, sam,
&m_hKey);
}

CReg(HKEY hkRoot, LPCTSTR pszKey) {
m_hKey = NULL;
m_Index = 0;
m_lpbValue = NULL;
Open(hkRoot, pszKey);
}

CReg() {
m_hKey = NULL;
m_Index = 0;
m_lpbValue = NULL;
}

~CReg() {
if(m_hKey) RegCloseKey(m_hKey);
MyFree(m_lpbValue);
}

void Reset() {
if(m_hKey) RegCloseKey(m_hKey);
MyFree(m_lpbValue);
m_hKey = NULL;
m_Index = 0;
m_lpbValue = NULL;
}

operator HKEY() { return m_hKey; }

BOOL IsOK(void) { return m_hKey!=NULL; }


BOOL EnumKey(LPTSTR psz, DWORD dwLen) {
if(!m_hKey) return FALSE;
return ERROR_SUCCESS==RegEnumKeyEx(m_hKey, m_Index++, psz,
&dwLen,
NULL,
NULL, NULL, NULL);
}

BOOL EnumValue(LPTSTR pszName, DWORD dwLenName, LPTSTR
pszValue,


.

Relevant Pages

  • Re: VS2005 compatibility
    ... Thanks for your info, Paul. ... I know the Link have the Heap and Stack memory settings. ... The EXE could really be bad. ... You say "I can download the program to the target device to run it". ...
    (microsoft.public.windowsce.app.development)
  • Re: Writing Device Drivers in Visual Studio
    ... I'll try to look at those settings in more detail or maybe someone else will ... Paul T. ... The target is connected via Ethernet. ... I compared the setting of the DLL project with these working projects - ...
    (microsoft.public.windowsce.platbuilder)
  • Re: [9fans] plan9 httpd/pegasus on unix?
    ... I've got to maintain a several hundred packages for our emedded target ... > - Makefile dependencies only work with the timestamps on files. ... "make clean" after changing toolchain settings should be obvoius. ... >>> you're running qmail on the host and really can't afford to stop it ...
    (comp.os.plan9)
  • Re: Installing K6-2 333MHZ on TX97-XE from k6 166MHZ
    ... So Paul or anyone in the know would this increase the hard drive bus ... Would you advise Paul or others that I don't mess with the FSB to avoid ... from searching the web and found undocumented settings. ...
    (alt.comp.periphs.mainboard.asus)
  • Re: Installing K6-2 333MHZ on TX97-XE from k6 166MHZ
    ... The same settings can be used with the 350, and maybe other chips, with no problems. ... BUS ratio: ... Would you advise Paul or others that I don't mess with the FSB to avoid ...
    (alt.comp.periphs.mainboard.asus)