Excerpt-the case of the missing ordinal

The case of the missing ordinal

Mike hall

Microsoft Corporation

Steve Maillet

Entelechy Consulting

March 10,200 3

Summary:Mike hall takes a look at missing ordinals from coredll. DLL and how to determine what's missing. he also discusses adding an MFC-based application to a Windows CE. net Operating System image. (10 printed pages)

 

now that the RTM bits for the Microsoft. NET Compact framework are available for download, I thought it was about time I started writing some C #. NET Compact framework applications. I really enjoy writing C # desktop applications, and wanted to get a feel for the development process using Microsoft Windows CE. net. I had a fairly old version of Microsoft Visual Studio. NET 2003 installed on my laptop (more on this later, since using the old version of the tools uncovered an interesting debug message in platform builder ), and used this to build a fairly simple C # application. I wanted to build two Operating System Images: one that matches des the final. NET Compact framework components, and one that requires Visual Studio. and install the. NET 2003 to download and install. NET Compact framework components on my target device.

rather than use the emulator, I 've been using an SH4-based reference board to build and test C # applications. don't get me wrong, the emulator is great, and I have been using this to test out my. NET Compact framework applications, especially when on recent flights to the Windows Embedded developers conferences in Asia. (I doubt that the cabin crew wowould have been impressed with mini hubs, network cables, and reference boards being used on a flight .) I wanted to get a feel for how application development wocould be with a "real" board, and how similar the experience wocould be to using the emulator. so I deployed an application to a device that didn't have. NET Compact framework supported ded. in this scenario, Visual Studio. NET 2003 will download and install the appropriate CAB files. the application failed to launch, and I got the following debug message in platform builder.

Error: function @ ordinal 1172 missing in module "coredll. dll"

Please check your sysgen variable !!!

This is intriguing, as the same application deploys and launches just fine in the emulator. in fact, this is the first time I 've ve seen such a message, so I figure it's time for some detective work. there must be a difference between the operating system running in the emulator and the operating system running on the reference board, but how to determine what's missing?

After thinking about this for a few seconds, the answer to this issue became somewhat obvious:. NET Compact framework requires a function that's not exposed from my version of coredll. DLL, And this is ordinal 1172. (Boy, wouldn't a function name be useful here instead of an ordinal? This wowould immediately show me which component or technology is missing from my operating system image .)

If you 've developed any Win32 code on the desktop, you will know that DLLs typically export their functions through. def file, so all we need is. def file for coredll. this is where we all say a big hoorah for the shared source that ships with Windows CE. net. take a look in this folder: C: \ wince410 \ private \ winceos \ coreos \ core \ DLL

There are a bunch of interesting files in this folder-perhaps APIs. C is worth a look sometime in the future. but wait, we were going to take a look at coredll. def. let's open up coredll. def in some appropriate Editor, like Notepad, or some other such editor wocould be just fine; after all we're re just looking for ordinal 1172 in the text file. so search for 1172... and there it is-sipgetinfo @ 1172.

; @ Cesysgen if coredll_coresip sipstatus @ 1169 sipregisternotification @ 1170 progress @ 1171 ----------> sipgetinfo @ 1172 <---------- sipsetinfo @ 1173 sipenumim @ 1174 progress @ 1175 progress @ 1176 progress @ 1214; @ cesysgen endif
 

It wowould appear that the. NET Compact framework required the SIP or soft Input Panel. Adding this component to my platform resolved the issue.

Remember that I pointed out that I was running a very early build of Visual Studio. NET? After pinging the folks in. NET Compact Framework Team, I determined that RTM Compact framework bits don't have the dependency on the soft Input Panel, and once I 'd installed a more recent build of Visual Studio. NET 2003, I cocould then deploy. NET Compact framework and my application without any issues (even though the operating system didn't have the SIP ). that'll teach me to play with Beta products...

actually, in some ways I'm quite pleased I saw this issue. this gave me the opportunity to find something out about Windows CE that I hadn't looked at before.

we typically run an "ask the experts" session at the windows embedded developers conferences. these are just great. delegates get to ask any and all questions they have around developing for Windows Embedded. (Let's not forget Microsoft Windows XP embedded here !). It can be fun to write code samples on the fly, to show how to do something, or to dive into the product documentation to show useful articles-not to mention to look at code samples you guys bring to the conferences. in our respects this feels much more like "try to stump the expert. "Anyhow, at the recent Windows Embedded Developers Conference in Beijing, China, a delegate was asking questions Bout developing MFC applications on Windows CE. net. the final question was, "Okay, so once I 've finished my application, how do I now get this application into my final Operating System image? "

now there's a good question. there are two parts to the answer. first, since this is MFC, we will need to include the MFC runtimes in our operating system. does this sound familiar? It shoshould. remember that my. NET Compact framework application wouldn't run because some of the required operating system components didn't exist in the operating system image. the second step is to modify bib, dat, and Reg files to include the application and any associated files into the final operating system build.

to walk the steps needed to include an MFC application into a Windows CE. net Operating System image, I 've built a simple "release build" MFC single document application. now we need to know which DLLs the application uses so that we can also make sure that these are supported in the operating system. there are a couple of ways to do this. the first is to use depends.exe (this ships with Embedded Visual C ++ 4.0), and the second is to use dumpbin.exe (a command-line tool that ships with Windows CE. net ). note that to use the command-line tool, you will need to ensure that your path is set up correctly. if you are working on a platform in platform builder, simply use build | open build release directory , and the paths will all be set up okay. trying to use dumpbin from a regular cmd window will give the "dumpbin is not recognized as an internal or external command" error.

below is the output from dumpbin when I look at the imports for my MFC-based application (command line is dumpbin/imports mfcdemo.exe ). we can see that the application needs mfcce400.dll and coredll. DLL.

Microsoft (r) COFF/PE dumper version 6.24.2064copyright (c) Microsoft Corporation. all rights reserved. dump of file mfcdemo.exe file type: executable image section contains the following imports: mfcce400.dll 13028 import Address Table 12630 Import Name Table 0 time date stamp 0 index of first forwarder reference ordinal 2074 ordinal 1034 ordinal 1351 ordinal 2122 ordinal 1150 ordinal 1 941 ordinal 2124 ordinal 2117 ordinal 2241 ordinal 1254 ordinal 837 ordinal 1841 // Note: I 've removed some of the listing // since this is quite long enough ~~â... Ordinal 201 ordinal 311 ordinal 2103 ordinal 1628 ordinal 2247 ordinal 1081 ordinal 779 ordinal 648 ordinal 1097 ordinal 1869 ordinal 2588 8C? Messagemap @ cwinapp @ 1uafx_msgmap @ B ordinal 1908 ordinal 2050 ordinal 1910 coredll. DLL 13000 import Address Table 12608 Import Name Table 0 time date stamp 0 index of first forwarder reference ordinal 86 ordinal 35 ordinal 33 ordinal 34 ordinal 84 ordinal 1645 ordinal 287 ordinal 267 ordinal 36 Summary 1000. data 1000. RDATA 2000. rsrc 1000. text

okay, now I bet you are really curious to find out what the nine functions are that are imported from coredll. DLL. go on, admit it; I bet you are just itching to go take a look at coredll. def now that you know where it is already existed â... Isn' t it strange how the two issues of the. NET Compact framework and including an MFC application into your device are somehow linked by the exported functions of coredll?

we now know that we must include mfcce400.dll and coredll. DLL. MFC is a component in the catalog; we just need to locate it in the tree, and then add it to our platform. note that this is only true of release applications. the debug version of MFC is not supported in platform builder-Why wocould you ship a device with a debug build of an application? The good news is that Microsoft Embedded Visual C ++ will download mfcce400d. DLL to your target if you're building and running a debug version of the application. MFC can be found here in the catalog: catalog | core OS | display-based devices | Applications and Services | Microsoft Foundation Classes (MFC) . coredll must be present on all platforms.

The next step is to include the application into the operating system image. again, we can do this in a number of ways. these include creating a custom. CEC file that copies my application to the current _ flatreleasedir (build release directory from platform builder), and which also contains the appropriate bib information. alternatively, we cocould hand copy the MFC application to the build release directory and then modify the project. bib, which will then add the application to the operating system image.

Time for a handy tip: One way to always copy a file to the build release folder is to drop it into this folder: C: \ wince410 \ public \<Project_name>\ Wince410 \<Platform_name>\ Oak \ files.

<Project_name>Is the name of your current Windows CE. Net project, and<Platform_name>Is the name of the current reference platform you are using. (In the case of using the emulator, this wocould beEmulator.) I cocould therefore drop my MFC application into this folder, and this will be copied to the build release folder at build time. by the way, having the files in the build release folder doesn't mean they get included into the operating system image; this is controlled by binary image builder (bib) files.

Time for another handy tip: excluding an application from your operating system image can be useful when you're debugging the application. Right-click on a user feature in the catalog, and then clickSettings. The following dialog will be displayed:

Figure 1. including or excluding an application from a build

You have three options:

1. Build and include in the operating system. This is the default option.
2. Build and exclude from the operating system. This is useful if you want to debug and rebuild the application without needing to rebuild the operating system. You can useTarget|Run programsTo get a list of available applications from your build release folder. this list will include applications that were both defined in the operating system and applications that have been built but excluded from the operating system. you can then push the application to the running operating system, try it out, catch a bug, kill the application, Recode, build, and push back to the device-kinda neat !
3. Don't build, and exclude from the operating system. This is self-explanatory.

Bib files have two sections, modules and files. modules are executable items, and files are just that, files, bitmaps, sounds, documents and so forth.

Assuming we have an application called myapp.exe, We wocould modify project. bib as follows:

; Copyright (c) Microsoft Corporation. all rights reserved .;;; use of this source code is subject to the terms of the Microsoft end-user; License Agreement (EULA) under which you licensed this software product .; if you did not accept the terms of the EULA, you are not authorized to use; this source code. for a copy of the EULA, please see the license. RTF on your; install media .; modules; name path memory type; -------------- emerge ----------- myapp.exe $ (_ flatreleasedir) \ myapp.exe NK sfiles; name path memory type; -------------- skip ----------- 

This will include myapp.exe into the \ Windows folder on the device. you can, if needed, also remap the application to another folder on the device. you wocould use. DAT files to make this happen. perhaps this wocould be an interesting subject for a future article. let me know if you 'd like us to take a look at that.

We can see that myapp.exe is stored in the final Operating System image both by looking at the build output window (see section below), and because we didn't get any build errors.

connpnl. cpl. text 814d3000 4096 1536 1127 o32_rva = 00001000
connpnl. cpl. rsrc 814d4000 8192 5632 5284 o32_rva = 00003000
stguil. cpl. text 814d6000 12288 11264 11222 o32_rva = 00001000
stguil. cpl. rsrc 814d9000 12288 8704 8220 o32_rva = 00005000
myapp.exe. text 814dc000 4096 3072 2856 o32_rva = 00001000
myapp.exe. RDATA 814dd000 4096 3072 2608 o32_rva = 00002000
myapp.exe. rsrc 814de000 8192 7680 7564 o32_rva = 00004000
memleak.exe. text 814e0000 4096 3072 2702 o32_rva = 00001000
memleak.exe. RDATA 814e1000 4096 512 380 o32_rva = 00002000
dmatrans. DLL. text 814e2000 8192 4608 4127 o32_rva = 00001000
ceemulsrv.exe. text 814e4000 4096 2560 2106 o32_rva = 00001000
ceemulsrv.exe. RDATA 814e5000 4096 512 220 o32_rva = 00002000
dc21x4. DLL. text 814e6000 65536 65024 64617 o32_rva = 00001000
DDI. DLL. text 814f6000 110592 110080 109996 o32_rva = 00001000

The other way of determining whether our application was defined ded or not is to run the application.

Figure 2. myapp.exe in the \ Windows folder of my device

That's it for this month. we 've already made a start on next month's article. unfortunately, I can't tell you what we're re writing about yet-Don't you just love surprises?