/* The contents of this file are subject to the Mozilla Public License * Version 1.1 (the "License"); you may not use this file except in * compliance with the License. You may obtain a copy of the License at * http://www.mozilla.org/MPL/ * * Software distributed under the License is distributed on an "AS IS" * basis, WITHOUT WARRANTY OF ANY KIND, either express or implied. See the * License for the specific language governing rights and limitations * under the License. * * The Initial Developer of the Original Code is Johannes Rudolph. * Portions created by the Initial Developer are Copyright (C) 2006 * the Initial Developer. All Rights Reserved. * * Contributor(s): * Johannes Rudolph */ = C++ exceptions in native programs = This native api program/library uses C++-features like classes in many places. This seems to work without problems so far. It would be appropriate to use C++ exceptions as well. This won't work. At least not with much effort. C++ exceptions are working through the subtle mechanisms of Windows, the C++ compiler *and* the runtime library working together. To use exception handling one has to enable the specific options in the compiler. You can use this lines in your SOURCES to enable it: {{{ USE_NATIVE_EH=1 USE_RTTI=1 }}} If we don't link a runtime library linking will error with unresolved externals like __CxxFrameHandler and others. Since we can't use Win32 dlls in a native program we can't link against the standard rt (msvcrt). So the right choice seems to be the use of the staticly linkable runtime library libc. This does not work either. Even libc contains uncountable references to functions defined in kernel32 and user32. We cannot link to them, of course. So your choices are: * reimplement C++ exception handling on top of the native (API) features provided by Windows and the compiler * use structured exception handling as documented by Microsoft, this will not work in functions relying on automatic object deconstruction * don't use exceptions at all (that was my choice)