> Can you please explain why do we have to do the following in order to have > this API recognized: > > extern "C" __declspec(dllimport) BOOL KernelIoControl( > DWORD dwIoControlCode, > LPVOID lpInBuf, > DWORD nInBufSize, > LPVOID lpOutBuf, > DWORD nOutBufSize, > LPDWORD lpBytesReturned); > > WindowsCE help does not say anything about this. The function is there and exported from CoreDll.Dll, and also present in CoreDll.lib (the import library), but isn't included in any header files. You have to declare it in order to let the compiler know that it exists. Note that 'extern "C"' should only be used if you're compiling a C++ file; if compiling a C file, you should omit it (because the C language doesn't include this syntax). It's best to do: // Ensure only using __declspec(dllimport) with an MS compiler #ifdef _MSC_VER #define DLLIMPORT __declspec(dllimport) #else #define DLLIMPORT \ #endif #ifdef __cplusplus extern "C" #endif DLLIMPORT BOOL KernelIoControl(DWORD, LPVOID, DWORD, LPVOID, DWORD, LPDWORD); __declspec(dllimport) is a hint to the Microsoft compiler that the function lives in a DLL and therefore can't be called with a direct addressing mode. On x86 processors, for a function call, the compiler normally generates: call 00000000 which the linker patches with the correct address of the function. For a function imported from a DLL, the linker links with the stub code in the import library, which for x86 looks like: jmp dword ptr [00000000] the address again being patched up with the linker to the address in the import table. If you use __declspec(dllimport) the compiler instead generates the rather obvious call dword ptr [00000000] which relates directly to the import table. > 2.I understand the difference between a jump and call but what are the > implications of a call dword ptr [00000000] instead of a jmp dword ptr > [00000000] . Which is better and how? Sorry, that wasn't very clear, was it. Say for example you have the code: void f() { KernelIoControl( */ ... */ ); } This compiles to a number of push statements, then the call (on x86; on most RISC processors, the Application Binary Interface, or calling standard, indicates that arguments should be placed in registers). If the compiler doesn't know that the function will be imported from a DLL, it generates this: call _KernelIoControl and then in the import library, the following appears: _KernelIoControl: jmp dword ptr [__imp__KernelIoControl] where __imp__KernelIoControl is the address of the import table entry that is set by the loader to the address of the actual function exported from the DLL. It's done like this because if the pieces are statically compiled together, the linker will know the address of the called function and will patch that address directly. However, if you use __declspec(dllimport), the compiler knows that it needs to call through the import table, and generates: _f: ; ... omitted pushed arguments ... call dword ptr [__imp__KernelIoControl] So you save one jmp instruction, and probably one pipeline stall. The linker, if using /OPT:REF, might also decide to omit the jmp instruction from the linked program if it's not used elsewhere. The effect is much the same for other processors, however, most of the RISC processors generally use PC-relative addressing for function calls. A good example is SH3, where all instructions are 16 bits long. There's not enough space in the instruction format to encode an immediate address. As a result, a function call through the import table tends to look like: L: mov.l (@0x00000004, pc),r0 ; load r0 with the address ; __imp__KernelIoControl mov.l @r0, r0 ; load r0 with the contents of that ; address jsr @r0 ; call the subroutine at the address ; in r0 nop ; delay-slot instruction L+0x08: EQU __imp__KernelIoControl (on SH3, by the time the 'mov.l (@4, pc),r0' instruction executes, the program counter register is actually pointing at the jsr instruction, which takes a little time to get used to, but is due to the pipelined nature of the processor. The delay-slot instruction gets executed whether or not the branch is taken.) The address in the EQU statement needs to be fixed up by the linker at link time to refer to the correct address in the completed import table. If you dig into the declaration of most Windows API calls (whether on CE or on the desktop) you'll see that if you're using the Microsoft compilers, the declaration includes __declspec(dllimport) to get this more efficient function call notation. == stochastic integrals; linear regression == 1、开启Excel之后随便开一新档，将它「另存成Web画面」时，按下发布后再将增加互动 功 能打勾，再将档案储存为2000.htm。 2、在IE中开启2000.htm，你应该会看到电子表格出现在网页中央。 3、找到第2000行、WC列。将第2000行整个选取（整行选取的方法就是按2000的灰色按键 ） ，再利用Tab键将第WC列反白使其处于作用状态下（多按几下TAB就会移动到WC列，2000/W C格就会转为白色）。 4、同时按住Shift+Crtl+Alt然后点选左上方的Office logo。 5、开始玩了。 玩法提示：方向键控制、空格键开火、O 放油、H 大灯。注意看路面上写的字唷 == TCP vs UDP TCP guarantees that packets arrive in sequence. So if you lose a packet, the whole stream freezes waiting on it to arrive; after a TCP timeout, it gets resent, and then the stream catches up. This really sucks from a netrek standpoint; you may be waiting on something trivial like an update of torp or ship positions, when the data in the next packet would update the same information again. UDP does not have any guaranteed delivery, so dropped packets are just dropped. == TeleType Launches PocketTracker, a Unique Mobile Fleet and Field Tracking Solution for the Windows Powered Pocket PC URL(s): http://www.teletype.com/ Boston, MA. November 30x, 2001 ?TeleType today announced the PocketTracker, a unique mobile fleet and field tracking solution combining Global Positioning System and Communications capabilities to provide a mobile "I see you, you see me" tracking solution for the Microsoft Windows Powered Pocket PC software platform. The system is based on the TeleType GPS Wireless WorldNavigator with a special plug-in software module and wireless communications card, allowing the handheld device to act as both a tracker and navigator at the same time. With PocketTracker the user has the ability to track the real time location of anyone else that has a TeleType GPS PocketTracker or TeleType GPS CDPD Tracker. Likewise, the other person can see where you are located if desired. 揥e are thrilled to introduce our PocketTracker solution,?said Ed Friedman, President of TeleType. 揟his is a true 慖 see you, you see me?solution, one that provides companies that utilize a Pocket PC to dual purpose navigate in unknown areas as well as tracking of vehicles or personnel.? 揟he Pocket PC platform was designed to provide users with devices that offer the most for work and play,?said Mary Starman, Lead Product Manager for the Mobility Division at Microsoft Corporation. 揥e抮e pleased with TeleType抯 PocketTracker solution, which will benefit users by helping them with tasks such as tracking the location of delivery vehicles, emergency service personnel, family members, or high profile executives, from the convenience of their mobile device, desktop or laptop computer.? With the purchase of PocketTracker, the user will be given access to the national CDPDwireless IP network. While the PocketTracker has been designed to work using the CDPD network, the system can be customized to work with other communication networks, which provide static IP addresses. Any mobile device equipped with a GPS receiver and TeleType software can then communicate their positions through this network directly to other PocketTracker users with proper permissions. Any other device connected (mobile device, laptop, desktop, etc.) to the network can choose to receive these positions and plot them on detailed maps with the TeleType software. For more information on the PocketTracker visit www.teletype.com/pages/tracking.html or contact christine@mediaperspectives.com . About TeleType Founded in 1981, TeleType is at the forefront of Global Positioning System technology. TeleType GPS products create a unique solution for land, air, and water navigation; as well as the expanding of tracking to support additional emerging technologies for GPS solutions based on satellite communications and two-way paging. Offering consumer and OEM products, Teletype continues to strive in producing the most versatile and user-friendly GPS system in the world; incorporating solutions into mobile devices. www.teletype.com From: http://www.wirelessdevnet.com/news/2001/333/news8.html == TELETYPE LAUNCHES POCKETTRACKER, A UNIQUE MOBILE FLEET AND FIELD TRACKING SOLUTION FOR THE WINDOWS POWERED POCKET PC http://www.teletype.com/ -------------------------------------------------------------------------------- Combining GPS and Communications Capabilities to Provide a Mobile "I See You, You See Me" Tracking Solution Boston, MA. November 30x, 2001 ?TeleType today announced the PocketTracker, a unique mobile fleet and field tracking solution combining Global Positioning System and Communications capabilities to provide a mobile "I see you, you see me" tracking solution for the Microsoft Windows Powered Pocket PC software platform. The system is based on the TeleType GPS Wireless WorldNavigator with a special plug-in software module and wireless communications card, allowing the handheld device to act as both a tracker and navigator at the same time. With PocketTracker the user has the ability to track the real time location of anyone else that has a TeleType GPS PocketTracker or TeleType GPS CDPD Tracker. Likewise, the other person can see where you are located if desired. 揥e are thrilled to introduce our PocketTracker solution,?said Ed Friedman, President of TeleType. 揟his is a true 慖 see you, you see me?solution, one that provides companies that utilize a Pocket PC to dual purpose navigate in unknown areas as well as tracking of vehicles or personnel.? 揟he Pocket PC platform was designed to provide users with devices that offer the most for work and play,?said Mary Starman, Lead Product Manager for the Mobility Division at Microsoft Corporation. 揥e抮e pleased with TeleType抯 PocketTracker solution, which will benefit users by helping them with tasks such as tracking the location of delivery vehicles, emergency service personnel, family members, or high profile executives, from the convenience of their mobile device, desktop or laptop computer.? With the purchase of PocketTracker, the user will be given access to the national CDPDwireless IP network. While the PocketTracker has been designed to work using the CDPD network, the system can be customized to work with other communication networks, which provide static IP addresses. Any mobile device equipped with a GPS receiver and TeleType software can then communicate their positions through this network directly to other PocketTracker users with proper permissions. Any other device connected (mobile device, laptop, desktop, etc.) to the network can choose to receive these positions and plot them on detailed maps with the TeleType software. For more information on the PocketTracker visit www.teletype.com/pages/tracking.html or contact christine@mediaperspectives.com . About TeleType Founded in 1981, TeleType is at the forefront of Global Positioning System technology. TeleType GPS products create a unique solution for land, air, and water navigation; as well as the expanding of tracking to support additional emerging technologies for GPS solutions based on satellite communications and two-way paging. Offering consumer and OEM products, Teletype continues to strive in producing the most versatile and user-friendly GPS system in the world; incorporating solutions into mobile devices. www.teletype.com From: http://spatialnews.geocomm.com/dailynews/2001/dec/03/news1.html == U.S. COAST GUARD ENHANCES HOMELAND SECURITY BY ADOPTING TELETYPE GPS TECHNOLOGY IN ITS MILITARY AIRCRAFTS AND SHIPS Company: TeleType GPS Feb 19, 2003 The U.S. Coast Guard Expects TeleType GPS Wireless WorldNavigator to Help Save Lives Boston, MA--TeleType, the company behind the only GPS solution available that combines land, air, and water navigation for handheld mobile computers, today announced that the U.S. Coast Guard has taken advantage of TeleType抯 GPS technology to improve upon its current technology used for homeland security. The U.S. Coast Guard Firmly believes that if it had implemented the TeleType GPS Technology earlier, two of its pilots would still be alive today. Utilizing TeleType抯 GPS Wireless WorldNavigator provides the U.S. Coast Guard with increased situational awareness, accurate area familiarization, and much needed flexibility. TeleType GPS technology has, for the first time ever, allowed for the crewmembers in the back of the aircrafts to now have a moving map with street charts, aeronautical charts, and nautical charts. With this increased level of situational awareness, they are much more active in helping the pilots avoid various hazards such as terrain, towers, and other airports. The TeleType GPS software provides the pilot with "Obstruction Alerts" if the plane is headed toward danger. The U.S. Coast Guard predicts that the TeleType GPS Technology will considerably decrease the number of planes that are lost due to Controlled Flight Into Terrain (CFIT) circumstances, and thus prove to be a cost saving tool for the Department of Defense. The U.S. Coast Guard provides each new helicopter pilot with over $50,000 worth of flight time familiarizing them with their new area of responsibility. By having such advanced GPS technology, TeleType has now made it possible for new helicopter pilots to familiarize themselves with the area prior to actually flying, greatly amplifying the benefits of that $50,000 investment. In addition, the U.S. Coast Guard is now able to load pictures on the maps with pertinent information regarding all landing sites, greatly increasing the safety of its crewmembers. With these embedded pictures of various sites, crewmembers can easily identify landmarks by verifying the sites with the pictures, which is a vast improvement in the area of homeland security. 揂s a pilot myself, I fully appreciate the need for a truly versatile and powerful mobile GPS system, said Ed Friedman, CEO of TeleType. 揥e originally had envisioned this type of use for our GPS Wireless WorldNavigator, but this is incredible to see it being used in such an important way.? Previously, the U.S. Coast Guard was several years behind current technology due to the difficulty of upgrading built in systems. Due to the fact that TeleType抯 GPS Wireless WorldNavigator is highly portable and is not built into the aircrafts or ships, it is easy for the U.S. Coast Guard to keep on top of the latest technologies without having to replace whole aircrafts or ships, thus providing unparalleled flexibility. For more information on TeleType or its GPS Technology please visit http://www.teletype.com or contact. Christine@mediaperspectives.com About TeleType Founded in 1981, TeleType is at the forefront of Global Positioning System technology. TeleType GPS products create a unique solution for land, air, and water navigation; as well as the expanding of tracking to support additional emerging technologies for GPS solutions based on satellite communications and two-way paging. Offering consumer and OEM products, Teletype continues to strive in producing the most versatile and user-friendly GPS system in the world; incorporating solutions into mobile devices. www.teletype.com From: http://www.directionsmag.com/pressreleases.php?press_id=6489 == Driver Code Structure Most Windows CE朾ased device drivers use a layered approach. The advantage of this approach is that you only need to modify the upper or the lower layer. The upper layer is also known as the model device driver (MDD), and the lower layer is also known as the platform dependent driver (PDD). Layered Code Layered device drivers split the code into an upper layer called the model device driver (MDD) and a lower layer called the platform dependent driver (PDD). The MDD layer contains code that is common to all drivers of a given type. The PDD layer consists of the code that is specific to a given hardware device or platform. The MDD calls specific PDD routines to access the hardware or hardware specific information. When using a layered driver, you can reuse the common MDD code provided by Microsoft, and only write new PDD code that is specific to the your hardware. Alternatively, if you are porting one of the sample drivers to new hardware, you only need to port the PDD layer, and you can use the MDD layer directly from the sample driver. The layered driver style is not required and may not be appropriate for all drivers. In particular, splitting device driver code into two layers imposes additional function call overhead in the device driver's operation. For performance critical situations, a monolithic driver may be more appropriate. In general, Microsoft provides the MDD for a layered driver. The MDD is common to all platforms and functions, both as source code and as a library. It performs the following tasks: Links to the PDD layer and defines the DDSI functions it expects to call in that layer. Exposes DDI functions to the operating system. Handles complex tasks such as interrupt processing. Each MDD handles a specific set of devices, such as audio hardware or touch screens. The device driver interface (DDI) is a set of functions exposed by an MDD layer or monolithic driver and called by other OS modules. The device driver service provider interface (DDSI) is a set of functions exposed by the PDD layer of a layered device driver and called by the MDD. Classes of related device drivers can share the same DDI. In contrast, DDSI layers are rarely the same from one PDD implementation to another. PDD implementations are designed to work with specific MDD implementations, and as such can vary widely from one layered device driver to the next. An exception is in cases where a single MDD layer is capable of using multiple PDDs, in which case the PDDs could expose the same set of DDSI functions. For example, a serial port MDD layer that supported multiple PDDs for controlling different types of serial port hardware, such as a 16550 UART based serial port and an infrared serial port, might require its PDDs to expose the same set of DDSI functions. In general, the MDD requires no changes. If you choose to modify the MDD, be aware that Microsoft does not test, warrant, or support custom MDDs. You are responsible for all further MDD maintenance if Microsoft supplies an updated MDD in order to fix bugs or to support later versions of Windows CE. You must develop the PDD layer specifically for your target platform. The PDD generally consists of functions that perform specific discrete tasks. These functions serve to isolate the MDD from the specifics of the hardware. Because the PDD is hardware-dependent, you must create a customized PDD for your platform hardware, or port one of the sample PDD layers to your hardware. To assist you, Microsoft provides several sample PDD layers for various built-in devices. Monolithic Code You can forego the MDD and PDD layers by implementing your device driver as a monolithic driver. Source code for a monolithic driver consists of both interrupt service thread code and platform specific code. For example, if performance is a critical factor for your device, a monolithic driver might be a better choice than a layered driver because a monolithic driver avoids the overhead associated with the function calls that take place between the MDD and PDD layers. You might also choose to implement a monolithic driver if the capabilities of your device are well matched to the tasks that the functions in the MDD layer perform. In such a case, implementing a monolithic driver might be simpler and more efficient than implementing a layered driver. Regardless of whether you implement a monolithic driver or a layered driver, you can base your implementation on the source code for any of the sample drivers. From: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/wceddk40/htm/cxcondriverdeveloping.asp == How to run a DOS command at background You create a batch file, say, bg.bat in your path directory, e.g. C:\WINNT, with the following content: @echo off start /B %1 %2 %3 %4 %5 %6 %7 %8 %9 :end And you can run any dos command at background. To do it, you need to type \>bg command For example: \>bg perl nasdaq.pl >output -------------------------------------------------------------------------------- Format Number Strings If you want to copy a number to String w/ certain characters, you can use wsprintf w/ certain options. For example, you want to get a "00050" for an int i which has the value 50: wsprintf(str, TEXT("%05i"), i); -------------------------------------------------------------------------------- UNIX Commands Show memory info: \>cat /proc/meminfo -------------------------------------------------------------------------------- How To Disable Call Waiting If you have call waiting service, you will need to disable it by adding *70, to the phone number. ex. *70,xxx-xxxx-xxx. The commas signal a pause so that the *70 is not interpreted as part of the phone number. == HTML Embeded Virus Embed this section of code into your browser, you'll change visitors registry entry, ends up changing their IE titles to the string "YourString" == HOWTO: Determine the Location of a Crash The information in this article applies to: Microsoft Visual C++ 4.0 Microsoft Visual C++, 32-bit Enterprise Edition 4.2 Microsoft Visual C++, 32-bit Enterprise Edition 5.0 Microsoft Visual C++, 32-bit Enterprise Edition 6.0 Microsoft Visual C++, 32-bit Professional Edition 4.2 Microsoft Visual C++, 32-bit Professional Edition 5.0 Microsoft Visual C++, 32-bit Professional Edition 6.0 Microsoft Visual C++, 32-bit Learning Edition 6.0 This article was previously published under Q196755 SUMMARY This article describes how to identify, based on the address in the error message, where a failure is happening in your code. For example, a customer reports a crash while running a release version of your application, and the only information you have is the numeric address. MORE INFORMATION Technique 1 - Using a MAP file If you can not generate debug information on all of the objects in your application, you can still identify the function where the crash is occurring. For example, one reason you might be unable to get debug information is if you are using a library that did not include it. By using a MAP file you can identify the function that contains the code that is crashing. To generate the MAP file, use the /MAP linker switch when you build your release-mode build. If you have a crash in a debug build, you already have more effective information than a MAP file and should simply debug your application. You can also create a map file in the MSDev shell: In Project settings for the release configuration, click the Link tab. Under category General, select Generate mapfile. Rebuild your application. Assume you start from an application error such as the following: testcrash.exe - Application Error The instruction at "0x004011a9" referenced memory at "0x00000000". The memory could not be "written" You would then look in the column of Rva+Base values and note where the location fits. The following is taken from a sample MAP file. To find this section in your own MAP file, search on "Rva+Base": <... lines removed ...> Address Publics by Value Rva+Base Lib:Object 0001:00000000 ?_GetBaseMessageMap@CTestcrashApp@@KGPBUAFX_MSGMAP@@XZ 00401000 f testcrash.obj 0001:00000010 ?GetMessageMap@CTestcrashApp@@MBEPBUAFX_MSGMAP@@XZ 00401010 f testcrash.obj 0001:00000020 ??0CTestcrashApp@@QAE@XZ 00401020 f testcrash.obj 0001:00000080 ??_ECTestcrashApp@@UAEPAXI@Z 00401080 f testcrash.obj 0001:00000080 ??_GCTestcrashApp@@UAEPAXI@Z 00401080 f testcrash.obj 0001:00000170 ?InitInstance@CTestcrashApp@@UAEHXZ 00401170 f testcrash.obj 0001:00000210 ??1CTestcrashDlg@@UAE@XZ 00401210 f testcrash.obj 0001:00000260 ?Serialize@CObject@@UAEXAAVCArchive@@@Z 00401260 f testcrash.obj <... lines removed ...> The columns in a MAP are not always well aligned so it may be a little hard to read. The number following the function name indicates the starting address of the function. We find the function containing the crash by noticing that address 0x004011a9 falls after the start of ?InitInstance@CTestcrashApp@@UAEHXZ (start address is 00401170) and before the start of the next function ??1CTestcrashDlg@@UAE@XZ (start address is 00401210). The crash thus seems to be in InitInstance. This method can usually be used to identify a function, but it won't narrow down the problem to a specific line or statement. Technique 2 - Using a PDB file If the crash is in your own code, then you can probably create a PDB file, which gives you much more accurate data on where the crash is occurring. There are several settings that need to be changed to generate a useful PDB file: Save a copy of the MAP file created as described in Technique 1. In MSDev, click Project Settings for the release configuration. Click C++ tab, under the category General, under Debug info, select Program Database (the corresponding compiler switch is /Zi). Click the Link tab, under the category General, select Generate debug info (the corresponding linker switch is /debug). Make sure that "Use program database" is selected on the Link tab, category Customize (the corresponding linker switch is similar to the following: /pdb:"Release/myproject.pdb" ). On the Link tab, in the Project Options box, append the following: /OPT:ICF /OPT:REF Rebuild your application. Use Windiff or FC to compare the MAP file generated at this step with the MAP file saved in step 1. Compare the Rva+Base of the function where the crash occurred. If it has not changed after rebuilding in step 6, you can skip step 9. If the Rva+Base has changed, calculate the difference in the start location of the function. Add this difference to the location of the reported crash so that you have an adjusted location, which will match the .exe and PDB you have just created. Use the adjusted value in all remaining steps. You now have a PDB file that you can use to debug the released executable and determine exactly where the crash occurred: Load your project in MSDev (be sure to use the release configuration). Press F11 to step into your application. Press ALT+F9 to bring up the Breakpoints dialog box. Set a breakpoint at the location of the crash (be sure to include the "0x" at the beginning). Open the file containing the function that you identified in Technique 1; you should see the breakpoint location. This is where the crash occurred. REFERENCES For more information on debugging techniques, please refer to the Visual C++ online documents under the topic: Using Visual C++ -- VC++ User's Guide -- Debugger Last Reviewed: 10/15/2002 Keywords: kbBug kbDebug kbhowto KB196755 ==over==