From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: David Hunter Newsgroups: gmane.emacs.devel Subject: Re: Problem with image libraries on Windows (reprise) Date: Wed, 15 Jun 2005 23:46:16 -0400 Message-ID: <42B0F608.6030307@comcast.net> References: NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Trace: sea.gmane.org 1118894874 9173 80.91.229.2 (16 Jun 2005 04:07:54 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Thu, 16 Jun 2005 04:07:54 +0000 (UTC) Cc: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Jun 16 06:07:50 2005 Return-path: Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1DilfE-0002Kc-NP for ged-emacs-devel@m.gmane.org; Thu, 16 Jun 2005 06:07:37 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1DilkZ-0003XA-3T for ged-emacs-devel@m.gmane.org; Thu, 16 Jun 2005 00:13:07 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1DilkF-0003Sc-8a for emacs-devel@gnu.org; Thu, 16 Jun 2005 00:12:47 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Dilfp-0002GJ-HD for emacs-devel@gnu.org; Thu, 16 Jun 2005 00:08:13 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1DilfT-0001sW-Uc for emacs-devel@gnu.org; Thu, 16 Jun 2005 00:07:52 -0400 Original-Received: from [204.127.202.56] (helo=sccrmhc12.comcast.net) by monty-python.gnu.org with esmtp (Exim 4.34) id 1DilMI-0007H5-Q3 for emacs-devel@gnu.org; Wed, 15 Jun 2005 23:48:02 -0400 Original-Received: from [192.168.42.3] (pcp08774087pcs.mtlrel01.nj.comcast.net[68.36.32.221]) by comcast.net (sccrmhc12) with ESMTP id <2005061603462001200kpl74e>; Thu, 16 Jun 2005 03:46:20 +0000 User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en Original-To: Juanma Barranquero In-Reply-To: X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:38925 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:38925 Juanma Barranquero wrote: > Cause: > Documentation for the JPEG library states: " Microsoft C cannot pass > file pointers between applications and DLLs. (See Microsoft Knowledge > Base, PSS ID Number Q50336.) " I've been unable to find article > Q50336, probably because it is very old, but the description of the > problem seems to fit what I find. Moreover, tracing calls all the way > through NTDLL shows that the Windows library is receiving an non-valid > FILE * (but the image DLLs are receiving a valid one, so it is not a > problem in Emacs). I don't know about that particular KB article, but the issue still applies to recent MS Visual C runtimes (CRT). In short, FILE pointers are valid only within the instance of the CRT library that created them. As long as your application and all dependent libraries dynamically link to the CRT (MSVCRT.DLL), then all application and library code can share FILE pointers. However, if an application or library (module) statically links to a CRT (LIBC[MT].LIB), then that module must keep its FILE pointers to itself, as no other CRT library (static or dynamic) will be able to use them. This issue is not limited to FILE pointers, but also extends to include most CRT resources, including memory (malloc/free). You must not call one CRT's malloc and pass the block to another CRT's free; it won't work. I believe this sharing issue is also encountered if you attempt to share FILE pointers between the retail (MSVCRT.DLL) and debug (MSVCRTD.DLL) libraries. Additionally, due to the release of Visual C++ .NET, there is a whole new set of .NET CRT libraries (e.g., MSVCR71.DLL). The dynamic CRT library used by a given module depends on the version of C++ used to build it. It is possible to have linked all modules to a dynamic CRT, and still the process may end up loading both old and .NET CRTs to satisfy modules built on different C++ versions. I have no firsthand knowledge with sharing FILE pointers between the old CRTs and these new .NET CRTs, but I think Microsoft does say this is bad: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vclib/html/_crt_c_run.2d.time_libraries.asp The compiler flags that control CRT linking are given in the above article. The moral of this story: Encapsulate, obfuscate, and hide CRT resources. -Dave