Compiler design is probably a rather boring subject without a real-life example. However, it's a very important subject in the field of reverse code engineering. How to learn it in an entertaining way? well, if you haven't read The Art of Disassembly, then you should read it now. You can download it from many places on the net, for example:The Art of Disasembly
Chapter 2 in the book specifically explains about compiler design for x86 architecture. The book is a bit old. However, the knowledge contained in it is very fundamental.
Sunday, July 31, 2011
Sunday, July 24, 2011
_CRT_SECURE_NO_WARNINGS Error Message in Visual Studio 2010 (VC++)
Using "legacy"/"unsecure" I/O functions in Visual Studio 2010 would trigger error similar to this:
which results in this error:
If you insist on using the "legacy" code, the solution is to define the following preprocessor definitions in your Visual Studio 2010 project properties:
USE_STANDARD_FILE_FUNCTIONS;_CRT_SECURE_NO_WARNINGS;
The preprocessor definition can be accessed in this menu: Project|Properties(Alt+F7)|Configuration Properties|C/C++|Preprocessor|Preprocessor Definitions.
After defining USE_STANDARD_FILE_FUNCTIONS;_CRT_SECURE_NO_WARNINGS; in your Visual C++ project, you should be good to go.
Happy coding.
1>emufuncs.cpp(672): warning C4996: 'fopen': This function or variable may be unsafe. Consider using fopen_s instead. To disable deprecation, use _CRT_SECURE_NO_WARNINGS. See online help for details.
1> C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\include\stdio.h(234) : see declaration of 'fopen'
which results in this error:
1>peutils.cpp(64): error C3861: 'dont_use_fgetc': identifier not found
1>peutils.cpp(224): error C3861: 'dont_use_fseek': identifier not found
1>peutils.cpp(229): error C3861: 'dont_use_fread': identifier not found
1>peutils.cpp(247): error C3861: 'dont_use_ftell': identifier not found
If you insist on using the "legacy" code, the solution is to define the following preprocessor definitions in your Visual Studio 2010 project properties:
USE_STANDARD_FILE_FUNCTIONS;_CRT_SECURE_NO_WARNINGS;
The preprocessor definition can be accessed in this menu: Project|Properties(Alt+F7)|Configuration Properties|C/C++|Preprocessor|Preprocessor Definitions.
After defining USE_STANDARD_FILE_FUNCTIONS;_CRT_SECURE_NO_WARNINGS; in your Visual C++ project, you should be good to go.
Happy coding.
Sunday, June 5, 2011
Visual Studio 2010 Code Editor Bug (Applies to C++ Code Editing)
Visual Studio 2010 Code Editor has stability issues in several platforms (mine is Windows 2008 Server SP2 - x86) as described here. In that description, the guy was having a slow response in IntelliSense.
Unfortunately for me, I was not only experiencing the lag, but also frequent crashes which was very irritating. The cause is a dependency on Windows Automation API.
The Bug Fix can be downloaded at http://support.microsoft.com/kb/971513/. Apparently, Visual Studio 2010 has dependency on Windows Automation API v3.0 which didn't ship with Windows Server 2008 SP2 or Windows Vista and previous Microsoft OSes.
Hopefully, this helps poor souls out there who gets irritated during C++ development in VS2010.
Goodluck :-)
Unfortunately for me, I was not only experiencing the lag, but also frequent crashes which was very irritating. The cause is a dependency on Windows Automation API.
The Bug Fix can be downloaded at http://support.microsoft.com/kb/971513/. Apparently, Visual Studio 2010 has dependency on Windows Automation API v3.0 which didn't ship with Windows Server 2008 SP2 or Windows Vista and previous Microsoft OSes.
Hopefully, this helps poor souls out there who gets irritated during C++ development in VS2010.
Goodluck :-)
Monday, March 7, 2011
Developing Software for Embedded Systems
Developing software for embedded system is particularly challenging. Therefore you have to make sure:
1. You know how to get debugging messages out of the system during development. Otherwise countless nightmare will wait for you.
2. Always place a "failsafe" code inside your brand new code so that the system would always recover to a point where you would be able to restore the system back to previously known working condition.
Now, let me explain point 1. Because not all embedded system contains a display, the debugging messages usually forwarded to an UART. The reason is simple, UART is a very simple digital device to initialize. In present day x86 systems, UART usually resides in the SuperIO chip or in the southbridge chipset. A display is far more difficult to initialize compareed to UART and sometimes does not available in the target system. By using an UART, it is also easier to do debugging once the system is deployed.
Let's move to point 2. In some systems, you have to remove some sort of flash chip and flash it somewhere else to recover from a bad software. Therefore, in order to reduce the hassle, it's better to provide "failsafe" code whenever possible.
1. You know how to get debugging messages out of the system during development. Otherwise countless nightmare will wait for you.
2. Always place a "failsafe" code inside your brand new code so that the system would always recover to a point where you would be able to restore the system back to previously known working condition.
Now, let me explain point 1. Because not all embedded system contains a display, the debugging messages usually forwarded to an UART. The reason is simple, UART is a very simple digital device to initialize. In present day x86 systems, UART usually resides in the SuperIO chip or in the southbridge chipset. A display is far more difficult to initialize compareed to UART and sometimes does not available in the target system. By using an UART, it is also easier to do debugging once the system is deployed.
Let's move to point 2. In some systems, you have to remove some sort of flash chip and flash it somewhere else to recover from a bad software. Therefore, in order to reduce the hassle, it's better to provide "failsafe" code whenever possible.
Subscribe to:
Posts (Atom)
