Re: [frame_dev] Re: Compiler Selection

On Thu, 25 Oct 2007 15:20:27 -0000, “mhardy_arm_com” wrote:

>For version 7.2 and earlier, the FDK was built single threaded.
>Clients should therefore also be built single threaded, with the
>Runtime Library property set to “Single-threaded (/ML)”. But Visual
>Studio .NET 2005 does not support this option.
>
>So if you do use Visual Studio .NET 2005 to build clients for version
>7.2 and earlier, you will be linking the multi-threaded objects that
>it builds from your code with the single threaded libraries in the
>FDK. This can cause unstable behavior.

Very interesting. I just checked our own settings, and found that
we use three of the four possibilities. Our DLL plugins, m2rbook.dll
and m2gframe.dll, both are multithreaded. Our EXE plugin, runfm.exe,
is single-threaded. Our conversion DLLs (like dwhtm.dll), and the
conversion driver dcl.exe, are all multithreaded DLL, but since the
plugin runs them using the Win API CreateProcess(), they are all
isolated from Frame.

Checking the VS docs on this point, there are warnings about not
mixing static and DLL libraries in the same process, and of course
about not mixing debug and release. But not a word against mixing
single-threaded and multithreaded, which we are obviously doing
regardless of which the FDK uses, since we link to it with both.

Further, we build with a fine disregard of the stated FDK requirements
for Visual Studio. For a long time, we used the 5.5 FDK, and VS4.
The resulting plugins worked fine with every Frame version through
7.0, and possibly higher, but when we built runfm, an async client,
we were forced to go to FDK 6, which we still use. The FDK 6 docs
require VS6. No matter; we tested it using VS4 and it still worked
fine. So we kept using VS4… and it all runs just fine with all
Frame versions from 5.5.6 (6.0 for runfm) through 8.0. For several
thousand users… No problems during debugging, either.

We also mix Win API calls with FDK calls, sometimes on the same
objects. For example, the Conversion Designer for RTF has about
23 panels, each a separate dialog built with .dre files. We use
the FDK to init them and to read from them. But the FDK has no
way of moving that entire stack of dialogs as one piece, so as we
create each panel we get its HWND from Windows. Then we move it
around in sync with all the rest using the Win API. Works fine.

My conclusion is that there’s less to worry about than one might
think when mixing FDK versions, Frame versions, and compiler
versions and settings. I’m tempted to see if GCC will work… ;-)

– Jeremy H. Griffith, at Omni Systems Inc.
http://www.omsys.com/

Yahoo! Groups Links

To visit your group on the web, go to:
http://groups.yahoo.com/group/frame_dev/

Your email settings:
Individual Email | Traditional

To change settings online go to:
http://groups.yahoo.com/group/frame_dev/join
(Yahoo! ID required)

To change settings via email:
mailto:frame_dev-digest@yahoogroups.com
mailto:frame_dev-fullfeatured@yahoogroups.com

To unsubscribe from this group, send an email to:
frame_dev-unsubscribe@yahoogroups.com

Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/

Leave a Reply

You must be logged in to post a comment.