Linker Error
--------------
MS_LINK : fatal error LNK1181: cannot open input file '..\..\..\..\..\3gpstack\pd_streaming_lib\prj\lib_ppc2003_evc4\windows mobile 5.0 smartphone sdk (armv4i)\debug\etm_pd_stack_lib_ppc2003_evc4.lib'
Solution:
----------
The path of the library file "etm_pd_stack_lib_ppc2003_evc4.lib'" is too large.
It is less than the 255 characters but still it is the problem. if I copied my project directly to D:\ then I will not get any errors.
MSDN KB for LNK1181 Error:
--------------------------------------
SYMPTOMS
When you build a Microsoft Visual C++ .NET project in Microsoft Visual Studio .NET or a Microsoft Visual C++ 2005 project in Microsoft Visual Studio 2005, you may receive an error message that is similar to the following error message:
fatal error LNK1181: cannot open inputfile ‘f:\temp\test.obj’
Back to the top
CAUSE
This problem may occur when the path of the Intermediate file folder or the path of the Output file folder in the Visual C++ project starts with a leading backward slash (\). The IDE uses the drive from where it is launched. The IDE does not use the drive that the project uses.
Back to the top
WORKAROUND
To work around this problem, include the drive name for the Intermediate file folder and for the Output file folder. To edit the entries for the IntDir folder or for the OutDir folder, follow these steps:1. On the Project menu, click Properties Pages.
2. In the Properties Pages dialog box, click Configuration Properties.
3. In the General list, type new entries for the Output Directory items and for the Intermediate Directory items that include the drive names.
reference: http://support.microsoft.com/kb/839286
Thursday, August 28, 2008
Friday, August 22, 2008
How to connect the Windows Pocket PC(Not having SIM) to the Internet thru ActiveSync
How to connect the Windows Pocket PC(Not having SIM) to the Internet thru ActiveSync:
------------------------------------------------------------------------------------
Two ways to connect our Development mobile to internet;
1.Thru the ActiveSync connected System
2.Thru the LAN settings
Development mobile will not have any SIM card in it;
Thru Active Sync Connected System:
-----------------------------------------------------------
To Select this mode we have to keep in mind the following things:
1.we must configure the Proxy server to the IE settings
2.USB Setting must be Turbo Mode;
How to Configure it:
----------------------------
Select Settings->Connections->connections->Tasks-> Set up Proxy server
general tab
Enter the name for the Settings: "Internet"
Proxy settings Tab:
-------------------------------
Enable the check boxes
1.this network connects to the internet option and
2.This network uses a proxy server to connect to the internet and enter the Proxy server address.
ProxyServer: 10.202.202.20
and click on OK.
Settings->Connections->connections has two tabs...
1.Tasks
2.Advanced
In the Advanced tab, click on "Select Networks" button.
Network Management page will appears.it has two combo boxes.
Select the "Internet" (description given in General Settings ) in both the combo boxes.
and then click on OK.
Moreover we have to set the "USB setting" mode as Turbo Mode;
Select the following option button:
Settings->connections->USB setting-> ActiveSync(Turbo Mode)
Restart the device to make the new Active Sync connection.
Now check the Internet explorer with URL.
LAN Based internet connection:
------------------------------------------------
Thru LAN based connection, we can access the LAN ( Intranet websites also) sites.
To Select this mode we have to keep in mind the following things:
1.we must configure the Proxy server to the IE settings
2.USB Setting must be Turbo Mode;
How to Configure it:
------------------------------
Select Settings->Connections->connections->Tasks-> Set up Proxy server or Edit my proxy server
general tab
Enter the name for the Settings: "Internet"
Proxy settings Tab:
-------------------------------------
Uncheck the following check boxes
1.this network connects to the internet option and
2.This network uses a proxy server to connect to the internet and enter the Proxy server address.
ProxyServer: 10.202.202.20
and click on OK.
Settings->Connections->connections has two tabs...
1.Tasks
2.Advanced
In the Advanced tab, click on "Select Networks" button.
Network Management page will appears.it has two combo boxes.
Select the "Internet" (description given in General Settings ) in both the combo boxes.
and then click on OK.
Moreover we have to set the "USB setting" mode as Normal Mode;
Select the following option button:
Settings->connections->USB setting-> ActiveSync(NormalTurbo
Restart the device to make the new Active Sync connection.
Now check the Internet explorer with URL.
------------------------------------------------------------------------------------
Two ways to connect our Development mobile to internet;
1.Thru the ActiveSync connected System
2.Thru the LAN settings
Development mobile will not have any SIM card in it;
Thru Active Sync Connected System:
-----------------------------------------------------------
To Select this mode we have to keep in mind the following things:
1.we must configure the Proxy server to the IE settings
2.USB Setting must be Turbo Mode;
How to Configure it:
----------------------------
Select Settings->Connections->connections->Tasks-> Set up Proxy server
general tab
Enter the name for the Settings: "Internet"
Proxy settings Tab:
-------------------------------
Enable the check boxes
1.this network connects to the internet option and
2.This network uses a proxy server to connect to the internet and enter the Proxy server address.
ProxyServer: 10.202.202.20
and click on OK.
Settings->Connections->connections has two tabs...
1.Tasks
2.Advanced
In the Advanced tab, click on "Select Networks" button.
Network Management page will appears.it has two combo boxes.
Select the "Internet" (description given in General Settings ) in both the combo boxes.
and then click on OK.
Moreover we have to set the "USB setting" mode as Turbo Mode;
Select the following option button:
Settings->connections->USB setting-> ActiveSync(Turbo Mode)
Restart the device to make the new Active Sync connection.
Now check the Internet explorer with URL.
LAN Based internet connection:
------------------------------------------------
Thru LAN based connection, we can access the LAN ( Intranet websites also) sites.
To Select this mode we have to keep in mind the following things:
1.we must configure the Proxy server to the IE settings
2.USB Setting must be Turbo Mode;
How to Configure it:
------------------------------
Select Settings->Connections->connections->Tasks-> Set up Proxy server or Edit my proxy server
general tab
Enter the name for the Settings: "Internet"
Proxy settings Tab:
-------------------------------------
Uncheck the following check boxes
1.this network connects to the internet option and
2.This network uses a proxy server to connect to the internet and enter the Proxy server address.
ProxyServer: 10.202.202.20
and click on OK.
Settings->Connections->connections has two tabs...
1.Tasks
2.Advanced
In the Advanced tab, click on "Select Networks" button.
Network Management page will appears.it has two combo boxes.
Select the "Internet" (description given in General Settings ) in both the combo boxes.
and then click on OK.
Moreover we have to set the "USB setting" mode as Normal Mode;
Select the following option button:
Settings->connections->USB setting-> ActiveSync(NormalTurbo
Restart the device to make the new Active Sync connection.
Now check the Internet explorer with URL.
Wednesday, August 06, 2008
Is it possible to call the function available in .obj code?
Is it possible to call the function available in .obj code?
Solution:
===========
yes.
But We can use it only in C file;In C++, we need further information;
I have developed the DLL project;
Within c file, We are able to call the function in obj code;
So within that DLL project, I have added the following
int ScaleRGB(int Width,int Height); available in object code;
Header.c:
--------
void ScaleRGB_Wrapper(int Width,int height)
{
ScaleRGB(width,height);
}
we have to add the .obj file to our DLL project;
within C code , call this ScaleRGB() fn and export the ScaleRGB_Wrapper() fn
as follows:
TESTDLL_API void ScaleRGB_Wrapper(int Width,int height)
{
ScaleRGB(width,height);
}
From the DLL client C++ application, call the ScaleRGB_Wrapper() function in a DLL;
Solution:
===========
yes.
But We can use it only in C file;In C++, we need further information;
I have developed the DLL project;
Within c file, We are able to call the function in obj code;
So within that DLL project, I have added the following
int ScaleRGB(int Width,int Height); available in object code;
Header.c:
--------
void ScaleRGB_Wrapper(int Width,int height)
{
ScaleRGB(width,height);
}
we have to add the .obj file to our DLL project;
within C code , call this ScaleRGB() fn and export the ScaleRGB_Wrapper() fn
as follows:
TESTDLL_API void ScaleRGB_Wrapper(int Width,int height)
{
ScaleRGB(width,height);
}
From the DLL client C++ application, call the ScaleRGB_Wrapper() function in a DLL;
Monday, August 04, 2008
Debug Mode and Release mode differences
Debug Mode and Release mode differences:
------------------------------------------------
Always test the application in both debug and release mode as a habit;
In debug mode, many of the compiler optimizations are turned off which allow the generated executable match up with the code. This allows breakpoints to be set accurately and allows a programmer to step through the code one line at a time. Debugging information is also generated help the debugger figure out where it is in the source code.
In release mode, most of the compiler's optimizations are turned on. Chunks of your code could be completely deleted, removed, or rewritten. The resulting executable will most likely not match up with your written code. However, normally release mode will run faster then debug mode due to the optimizations.
The biggest difference between these is that: In a debug build the complete symbolic debug information is emitted to help while debugging applications and also the code optimization is not taken into account. While in release build the symbolic debug info is not emitted and the code execution is optimized.Also, because the symbolic info is not emitted in a release build, the size of the final executable is lesser than a debug executable.
Note:
--------
One can expect to see funny errors in release builds due to compiler optimizations or differences in memory layout or initialization. These are ususally referred to as Release - Only bugs :)In terms of execution speed, a release executable will execute faster for sure, but not always will this different be significant.
Q:Why does program work in debug mode, but fail in release mode?A: First of all, there is no such thing as 'debug mode' or 'release mode'. The VC++ IDE offers the possibility to define configurations which include a set of project settings (like compiler / linker options, output directories etc.) When a project is created using AppWizard, you get two default configurations: "Win32 Debug" and "Win32 Release". These are just convenient starter configurations with several preset options which are suitable for typical debug builds or release builds respectively, but you are by no means restricted to those settings. Actually, you can modify those configurations, delete them, or create new ones. Now let's see what the two default configurations typically include and what distinguishes them:Win32 Debug:Subdirectory 'Debug' used for temporary and output filesPreprocessor symbol _DEBUG definedDebug version of the runtime libraries is usedAll compiler optimizations turned offGenerate debug infoWin32 Release:Subdirectory 'Release' used for temporary and output filesPreprocessor symbol NDEBUG definedRelease version of the runtime libraries is usedVarious compiler optimizations turned onGenerate no debug infoThere are a few other differences, but these are the most important ones. Now, what's the first implication of all this? That, as opposed to a common misunderstanding, you can debug a release build. Just go to 'Project -> Settings', choose the Win32 Release configuration, tab 'C/C++', 'General' and set 'Debug Info' to 'Program Database'. Then go to the tab 'Linker', and turn on 'Generate Debug Info'. If you rebuild your project now, you will be able to run it in the debugger. Regardless of whether your program crashes or just doesn't behave as expected, running it in the debugger will show you why. Note however, that due to optimizations turned on in the release build, the instruction pointer will sometimes be off by a few code lines, or even skip lines altogether (as the optimizer didn't generate code for them). This shouldn't be a concern, if it is, turn off optimizations.When debugging your release build this way, you will probably discover that at a certain point during execution, a variable has a different value in the release and in the debug build, causing the differing behaviour. And if you go back and see where the value of that variable is set, you will most probably find out that it isn't: You simply forgot to initialize that variable. The reason why the debug build seemed to work is that the debug version of the runtime library initializes dynamic memory and stack variables to known values (in order to track down memory allocation and overwrite errors), while the release version of the runtime library doesn't. This is by far the most frequent single cause for different behaviour between debug and release builds, so chances are good that this fixes your problem (and for the future, remember to always initialize your variables).If uninitialized variables were not the cause of your problem, let's look at the next possible difference between debug and release builds: The preprocessor symbols _DEBUG and NDEBUG. If you have any code inside an #ifdef _DEBUG / #endif block, it will not be contained in a release build. What's worse, the dependency of those symbols can be hidden inside other macros. A typical candidate for this is ASSERT: It expands to the assertion testing code if _DEBUG is defined, and to nothing if it is not. Therefore, be careful to have no code with side effects inside an ASSERT macro. For example, the following code will work in a debug build, but fail in a release build:CSomeDialog dlg;ASSERT(dlg.Create(IDD_SOME_DLG));dlg.ShowWindow(SW_SHOW);As a rule, never put code which needs to be executed inside an ASSERT. (A side note: Conditions which can be expected to fail at runtime, like the 'Create()' call in the example, should never be tested with ASSERTs anyway. Assertions are a tool to assert pre- and postconditions regarding your code, not runtime error conditions.)At this point, you have most probably found out why your code failed in the release build. If not, this might be one of the very rare cases where the compiler optimizations caused your code to behave differently (the VC++ compiler had several optimizer bugs in the past, and I doubt they have all been fixed). To exclude this, first turn all the optimizations off (Project -> Settings, tab 'C/C++', category 'Optimizations', option 'Disable (Debug)'). If your code works now, selectively turn optimization options on until you found the culprit. Simply leave it turned off, or upgrade to a newer version of the compiler (or install the most recent service packs) which might hopefully fix that bug.This should help you get your release build running in most of the situations. For a more in-depth discussion about the differences between debug and release builds, see the excellent article Surviving the Release Version
http://www.codeproject.com/KB/debug/survivereleasever.aspx
Incorrectly prototyped message handlers !Thats another big goof up everyone makes atleast once ...In the debug build, if you have incorrect message handler signatures this doesnt cause any problems.But MFC does a couple of naughty type casts in the message map macros. So when you build the same code in release mode, you are guranteed to run into trouble. As soon as your message handler returns, your stack frame gets trashed and you get a neat little GPF.
Some References:
http://www.codeproject.com/KB/debug/survivereleasever.aspx
http://www.codeproject.com/KB/debug/releasemode.aspx
------------------------------------------------
Always test the application in both debug and release mode as a habit;
In debug mode, many of the compiler optimizations are turned off which allow the generated executable match up with the code. This allows breakpoints to be set accurately and allows a programmer to step through the code one line at a time. Debugging information is also generated help the debugger figure out where it is in the source code.
In release mode, most of the compiler's optimizations are turned on. Chunks of your code could be completely deleted, removed, or rewritten. The resulting executable will most likely not match up with your written code. However, normally release mode will run faster then debug mode due to the optimizations.
The biggest difference between these is that: In a debug build the complete symbolic debug information is emitted to help while debugging applications and also the code optimization is not taken into account. While in release build the symbolic debug info is not emitted and the code execution is optimized.Also, because the symbolic info is not emitted in a release build, the size of the final executable is lesser than a debug executable.
Note:
--------
One can expect to see funny errors in release builds due to compiler optimizations or differences in memory layout or initialization. These are ususally referred to as Release - Only bugs :)In terms of execution speed, a release executable will execute faster for sure, but not always will this different be significant.
Q:Why does program work in debug mode, but fail in release mode?A: First of all, there is no such thing as 'debug mode' or 'release mode'. The VC++ IDE offers the possibility to define configurations which include a set of project settings (like compiler / linker options, output directories etc.) When a project is created using AppWizard, you get two default configurations: "Win32 Debug" and "Win32 Release". These are just convenient starter configurations with several preset options which are suitable for typical debug builds or release builds respectively, but you are by no means restricted to those settings. Actually, you can modify those configurations, delete them, or create new ones. Now let's see what the two default configurations typically include and what distinguishes them:Win32 Debug:Subdirectory 'Debug' used for temporary and output filesPreprocessor symbol _DEBUG definedDebug version of the runtime libraries is usedAll compiler optimizations turned offGenerate debug infoWin32 Release:Subdirectory 'Release' used for temporary and output filesPreprocessor symbol NDEBUG definedRelease version of the runtime libraries is usedVarious compiler optimizations turned onGenerate no debug infoThere are a few other differences, but these are the most important ones. Now, what's the first implication of all this? That, as opposed to a common misunderstanding, you can debug a release build. Just go to 'Project -> Settings', choose the Win32 Release configuration, tab 'C/C++', 'General' and set 'Debug Info' to 'Program Database'. Then go to the tab 'Linker', and turn on 'Generate Debug Info'. If you rebuild your project now, you will be able to run it in the debugger. Regardless of whether your program crashes or just doesn't behave as expected, running it in the debugger will show you why. Note however, that due to optimizations turned on in the release build, the instruction pointer will sometimes be off by a few code lines, or even skip lines altogether (as the optimizer didn't generate code for them). This shouldn't be a concern, if it is, turn off optimizations.When debugging your release build this way, you will probably discover that at a certain point during execution, a variable has a different value in the release and in the debug build, causing the differing behaviour. And if you go back and see where the value of that variable is set, you will most probably find out that it isn't: You simply forgot to initialize that variable. The reason why the debug build seemed to work is that the debug version of the runtime library initializes dynamic memory and stack variables to known values (in order to track down memory allocation and overwrite errors), while the release version of the runtime library doesn't. This is by far the most frequent single cause for different behaviour between debug and release builds, so chances are good that this fixes your problem (and for the future, remember to always initialize your variables).If uninitialized variables were not the cause of your problem, let's look at the next possible difference between debug and release builds: The preprocessor symbols _DEBUG and NDEBUG. If you have any code inside an #ifdef _DEBUG / #endif block, it will not be contained in a release build. What's worse, the dependency of those symbols can be hidden inside other macros. A typical candidate for this is ASSERT: It expands to the assertion testing code if _DEBUG is defined, and to nothing if it is not. Therefore, be careful to have no code with side effects inside an ASSERT macro. For example, the following code will work in a debug build, but fail in a release build:CSomeDialog dlg;ASSERT(dlg.Create(IDD_SOME_DLG));dlg.ShowWindow(SW_SHOW);As a rule, never put code which needs to be executed inside an ASSERT. (A side note: Conditions which can be expected to fail at runtime, like the 'Create()' call in the example, should never be tested with ASSERTs anyway. Assertions are a tool to assert pre- and postconditions regarding your code, not runtime error conditions.)At this point, you have most probably found out why your code failed in the release build. If not, this might be one of the very rare cases where the compiler optimizations caused your code to behave differently (the VC++ compiler had several optimizer bugs in the past, and I doubt they have all been fixed). To exclude this, first turn all the optimizations off (Project -> Settings, tab 'C/C++', category 'Optimizations', option 'Disable (Debug)'). If your code works now, selectively turn optimization options on until you found the culprit. Simply leave it turned off, or upgrade to a newer version of the compiler (or install the most recent service packs) which might hopefully fix that bug.This should help you get your release build running in most of the situations. For a more in-depth discussion about the differences between debug and release builds, see the excellent article Surviving the Release Version
http://www.codeproject.com/KB/debug/survivereleasever.aspx
Incorrectly prototyped message handlers !Thats another big goof up everyone makes atleast once ...In the debug build, if you have incorrect message handler signatures this doesnt cause any problems.But MFC does a couple of naughty type casts in the message map macros. So when you build the same code in release mode, you are guranteed to run into trouble. As soon as your message handler returns, your stack frame gets trashed and you get a neat little GPF.
Some References:
http://www.codeproject.com/KB/debug/survivereleasever.aspx
http://www.codeproject.com/KB/debug/releasemode.aspx
Local variable value changed only in release mode not in debug mode
I faced the problem like the following:
Local variable values are changed after the particular moment;The expected value is not placed in a variable;
Even though we are not changing the value;I faced this problem many times;But thought of it as a multi threading error;
Nature of Error:
---------------
This error is occured only in release mode not in debug mode;
and I have used the more local variables in a function;
Fix:
-------
I fixed the problem after calling the certain function the local variable value is changed;
void Test()
{
//variables ...
//....
//...
int i = 0;
i = 2;
InnerFn();
printf( i); // i value is around 158004
//Unknown reason
}
Solution:
--------------
it is not a multi threading error; Mostly the multi threading error affects only the global variables and class private or public members not a local variables;For Every Thread call, the stack variable is allocated and freed;
Problem is there is some memory leak in InnerFn() ; So it affects the local variables of a Test() fn;
After modified the memory leak problem in InnerFn(), the local variable value is not changed;the local variable have the expected value;
Local variable values are changed after the particular moment;The expected value is not placed in a variable;
Even though we are not changing the value;I faced this problem many times;But thought of it as a multi threading error;
Nature of Error:
---------------
This error is occured only in release mode not in debug mode;
and I have used the more local variables in a function;
Fix:
-------
I fixed the problem after calling the certain function the local variable value is changed;
void Test()
{
//variables ...
//....
//...
int i = 0;
i = 2;
InnerFn();
printf( i); // i value is around 158004
//Unknown reason
}
Solution:
--------------
it is not a multi threading error; Mostly the multi threading error affects only the global variables and class private or public members not a local variables;For Every Thread call, the stack variable is allocated and freed;
Problem is there is some memory leak in InnerFn() ; So it affects the local variables of a Test() fn;
After modified the memory leak problem in InnerFn(), the local variable value is not changed;the local variable have the expected value;
How to replace our video renderer with Microsoft's video renderer?
if we are developing our own renderer, then we have to make the media player to use our own
video renderer filter. what we have to do for it?
[HKEY_CLASSES_ROOT\CLSID\{70e102b0-5556-11ce-97c0-00aa0055595a}]
@="Video Renderer"
"Merit"=dword: 0x800000
and check its merit ;
Make our own Video Renderer filter's merit as follows
0x800000 + 1
Then Windows media player make use of our own video renderer filter;
Dshow loads filters based on merit; if the merit is high, then it will be preferred by the windows media player as well .
as Intelligent connect for connecting filters in a filtergraph.
video renderer filter. what we have to do for it?
[HKEY_CLASSES_ROOT\CLSID\{70e102b0-5556-11ce-97c0-00aa0055595a}]
@="Video Renderer"
"Merit"=dword: 0x800000
and check its merit ;
Make our own Video Renderer filter's merit as follows
0x800000 + 1
Then Windows media player make use of our own video renderer filter;
Dshow loads filters based on merit; if the merit is high, then it will be preferred by the windows media player as well .
as Intelligent connect for connecting filters in a filtergraph.
Subscribe to:
Posts (Atom)