xerces-c-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Steve Feinstein" <sfeinst...@anydevice.com>
Subject RE: deleting a transcode return results in assertion on windows
Date Thu, 02 Nov 2000 06:33:09 GMT
RE: deleting a transcode return results in assertion on windowsPerhaps they
are running, but since we're relying on the results of their incompetent
work, I choose to look for ways to protect my own nose from getting hit by
the rakes they have left in my yard - the kind with "invalid page fault"
written on them.  Statically linking those rakes to the toolshed seems like
a smart way to go.  Since I know what runs in my process and what runtimes
it uses, I should be OK.  I've got Xerces and my app linked with the same
runtime, so there is no mixing there.  How can I get burned in this
situation?
  -----Original Message-----
  From: Dean Roddey [mailto:droddey@charmedquark.com]
  Sent: Wednesday, November 01, 2000 9:21 PM
  To: xerces-c-dev@xml.apache.org
  Subject: Re: deleting a transcode return results in assertion on windows


  Then, in my opinion, they are just running from their own incompetence,
not improving the world. Why is that so much work was expended getting away
from monolothic systems? Because they suck! MS is just incapable of making a
great concept workable, so they are just trying to go back to what the
concept was created in order to avoid to begin with.

  --------------------------
  Dean Roddey
  The CIDLib C++ Frameworks
  Charmed Quark Software
  droddey@charmedquark.com
  http://www.charmedquark.com

  "It takes two buttocks to make friction"
      - African Proverb


    ----- Original Message -----
    From: Andy Heninger
    To: xerces-c-dev@xml.apache.org
    Sent: Wednesday, November 01, 2000 3:07 PM
    Subject: Re: deleting a transcode return results in assertion on windows


    Microsoft is trying hard to move away from the use of shared DLLs by
Windows applications.  See
http://msdn.microsoft.com/library/techart/dlldanger1.htm  for their take on
the issues and tradeoffs.  Or search for "DLL Hell" on their website.

    Andy Heninger
    IBM XML Technology Group, Cupertino, CA
    heninger@us.ibm.com

      ----- Original Message -----
      From: Dean Roddey
      To: xerces-c-dev@xml.apache.org
      Sent: Wednesday, November 01, 2000 2:01 PM
      Subject: Re: deleting a transcode return results in assertion on
windows


      Its not memory requirements I'm talking about, its the problems
associated with mixed runtimes in a single process. Any system in which the
reciever of any dynamically allocated buffer must know where it came from
and pass it back to there to be deleted is a screwed up system. We don't
need that kind of complexity in ow development lives. And mixed runtimes
gets you into that situation.

      While I understand that problems can occur when you use DLLs, the
concept behind them is unassailable in my opinion. If there are problems,
then they need to be dealt with. They are a fundamental aspect of all modern
operating systems AFAIK, and they will continue to be so. They have massive
benefits that are very important to keep. This is no different in a way than
having a new device driver installed, or doing an OS patch. All of these
things can break applications in the same way. But no one would suggest that
OSes go back to having to be rebuilt in order to install a device driver,
right?

      It will *always* be possible for a user to screw up his/her system
such that it costs you a huge amount of time and effort to debug why it
happened. Its just a fact of life in the non-big iron world where people
maintain their own systems. Its unfortunate, but its true. MS (and other OS
manufacturers) need to be more proactive in making them safer. In the
meantime, we will have to write more paranoid code I guess. But I don't
think that statically linking to the runtime is an answer. Any other DLL you
bring in could just as easily link dynamically to to the runtime, and you'd
still be (indirectly) screwed.

      And, of course, the flip side of this is that if MS puts out a fixed
runtime, all the apps that use it dynamically become better and yours
doesn't. The whole point of DLLs is that ability to update underlying
functionality separately if it needs to be. And if everyone links
statically, that means that more and more old and different versions of the
runtime are basically stuck on systems, making it that much more difficult
for the OS (or tool) vendor to be sure that you are using a particular
version etc...

      --------------------------
      Dean Roddey
      The CIDLib C++ Frameworks
      Charmed Quark Software
      droddey@charmedquark.com
      http://www.charmedquark.com

      "It takes two buttocks to make friction"
          - African Proverb


        ----- Original Message -----
        From: Steve Feinstein
        To: xerces-c-dev@xml.apache.org
        Sent: Wednesday, November 01, 2000 12:47 PM
        Subject: RE: deleting a transcode return results in assertion on
windows


        Well, dumpbin doesn't show it because I rebuilt it without the DLL
:-).

        I disagree that the alternative is necessarily worse.  We're talking
about a trade-off between robustness and efficiency, so the developer has to
decide what the risks are for a given application.  For mission critical
applications, I would rather throw in more memory and not have to worry
about "DLL hell".

        The theory is that if you dynamically link with the runtime code,
Windows will allow multiple processes to share that DLL.  The reality is
that Windows is not always able to do that, so you can end up with multiply
loaded DLLs anyway.  In the case of MSVCRT.DLL, it's only about 250KB, so
it's quite possible that you're not even impacting efficiency all that much.
It doesn't mean that  "every single exe and dll has its own copy", just the
ones that are built that way.  And if I have a mission critical application,
I don't want someone coming along and installing some incompatible MSDEV
application that suddenly changes heap management for my app.  I'd take a
hit on efficiency over a system crash any day.

        The "possible" incompatibilities are not just a "possibility".  Here
is the MSDN bug report:

        http://support.microsoft.com/support/kb/articles/Q190/5/36.ASP

        I happen to have had the pleasure of seeing this problem come up and
the harm done was infinitely more damaging than increasing the memory
requirements.

        If you really want to use the DLLs, then you should include code
that checks the versions of the DLLs you depend upon.  That way if someone
decides to install an old copy of WinZip on your box, you can raise a flag
before the page fault happens.
          -----Original Message-----
          From: Dean Roddey [mailto:droddey@charmedquark.com]
          Sent: Wednesday, November 01, 2000 2:07 PM
          To: xerces-c-dev@xml.apache.org
          Subject: Re: deleting a transcode return results in assertion on
windows


          Ummm.... No don't follow any of that advice.

          The parser is most definitely dependent upon the MS runtimes and
you should definitely *not* statically link to the runtime. Though what he
says about possible incompatibilties is a possibility, the alternative is
worse (i.e. every single exe and dll in the entire system having its own
copy.)

          The fact that memory management is per-runtime type, and the fact
that you cannot mix them, proves that we are dependent upon the runtime. Why
dumpbin doesn't show it, I dunno. But tools like chkmod32 clearly do show it
as a dependent library.

          --------------------------
          Dean Roddey
          The CIDLib C++ Frameworks
          Charmed Quark Software
          droddey@charmedquark.com
          http://www.charmedquark.com

          "It takes two buttocks to make friction"
              - African Proverb


            ----- Original Message -----
            From: Steve Feinstein
            To: xerces-c-dev@xml.apache.org
            Sent: Wednesday, November 01, 2000 10:49 AM
            Subject: RE: deleting a transcode return results in assertion on
windows


            I never use the Microsoft C runtime DLLs.  When you do that you
open yourself up to some other application installing its own version of
those shared DLLs which
            may be incompatible with the one you rely on and tested with.
Microsoft has completely changed heap management along the way to a "small
block" implementation.  The safest thing to do is to statically link with
the runtime library, so choose "Debug Multithreaded" and "Multithreaded".

            P.S. If you want to see if an already built library depends on
the runtime DLLs, just do a

                "dumpbin -imports <lib/exe filename>"  or a
                "dumpbin -dependents <lib/exe filename>"

            ...and look for something like msvcrt.dll.  For example, this
shows that the Xerces-C library is not dependent on that nasty DLL:

            C:> dumpbin -dependents xerces-c_1_3.dll

            Microsoft (R) COFF Binary File Dumper Version 6.00.8168
            Copyright (C) Microsoft Corp 1992-1998. All rights reserved.


            Dump of file xerces-c_1_3.dll

            File Type: DLL

              Image has the following dependencies:

                KERNEL32.dll
                USER32.dll
                ADVAPI32.dll
                WS2_32.dll

              Summary

                    4000 .data
                   3D000 .rdata
                    7000 .reloc
                    6000 .rsrc
                   58000 .text

              -----Original Message-----
              From: Nadav Aharoni (GENERIZE) [mailto:nadava@generize.com]
              Sent: Wednesday, November 01, 2000 1:16 PM
              To: 'xerces-c-dev@xml.apache.org'
              Subject: RE: deleting a transcode return results in assertion
on windows


              In my case, the DEBUG configuration of my application uses
DEBUG Multithreaded DLL and the RELEASE configuration uses Multithreaded
DLL.

              You should note that in the Project | Settings dialog in VC++
you can define different settings for different compile configurations of
your executable. In our case the debug configuration of you executable would
link with the D version of the library and use the "DEBUG Multithreaded DLL"
runtime. The relase configuration of your executable should use the non D
version of xerces libs and the "Multithreaded DLL" runtime.

              (Ok, this is really verbose, but I was a teacher, and know
that it's better then too concise...)




              -----Original Message-----
              From: Dennis Gearon [mailto:gearond@OIT.EDU]
              Sent: Wednesday, November 01, 2000 6:27 PM
              To: xerces-c-dev@xml.apache.org
              Subject: Re: deleting a transcode return results in assertion
on windows



              So, which one of the six runtimes does the 'D' version of the
library
              use? Does the note below tell how to find out?

              > The problem is almost certainly because of mixed runtimes.
              >
              >I agree: Had the same problem for me. When I had made sure to
use only debug
              >mode libs, all worked fine.
              >
              >Try to right-click on your executable (works on .EXE and
.DLL) in Windows
              >Explorer, select Quickview and scan the ImportTable for a
unmatching lib.
              >
              >As a hint to interprete the MS-DLL names you could see the
article-id
              >"Q154753" in the Microsoft knowledge base avaiable at
              >http://support.microsoft.com/.
              >
              >Perhaps you are using other DLLs which use unmatching libs. I
don't know
              >whether this is a problem at all.



              --

________________________________________________________________
              Dennis K. Gearon (Kegley)                           Loyal
Member
              Scientific Instrument Technician, School of ETM       of The
              Oregon Institute of Technology                       Order of
              - One of USA's Best College Buys                       TUX
              3201 Campus Drive                             ~
              Klamath Falls, OR 97601                      'v'    standards
              Voice   1-541-885-1563                      // \\
corrupters:
              FAX     1-541-885-1689                     /(   )\   ^phear^
              email   gearond@oit.edu                     ^`~'^   the
penguin

________________________________________________________________
              Happiness is when you want to go to your job in the morning
and
              when you want to go home in the evening.

________________________________________________________________


Mime
View raw message