Re: [vos-d] Re: struggling with Windows...

[Braden McDaniel]

On Tue, 2005-08-16 at 22:11 -0400, Peter Amstutz wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
> 
> On Tue, 16 Aug 2005, Braden McDaniel wrote:
> 
> >> One heap - you can free memory allocated in some other module.
> >
> > That's the major selling point. Doing without this is giving up a lot; 
> > nonetheless, I find myself considering strategies that would ameliorate its 
> > absence.
> 
> Yea, for VOS this is pretty much essential.  Besides the fact that most 
> classes in VOS are reference counted (so may be deleted anywhere),

That problem is solvable. For example, boost::shared_ptr lets you
specify a custom deleter function.

>  we pass 
> objects like std::string around between DLLs quite a bit which of course 
> does its underlying allocation on the heap.

But the Microsoft std::string implementation is not COW, so I don't
think this is a problem.

-- 
Braden McDaniel   e-mail: <[EMAIL PROTECTED]>
Jabber: <[EMAIL PROTECTED]>


___
vos-d mailing list
vos-d@interreality.org
http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d

Re: [vos-d] Re: struggling with Windows...

[Peter Amstutz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Tue, 16 Aug 2005, Braden McDaniel wrote:


One heap - you can free memory allocated in some other module.


That's the major selling point. Doing without this is giving up a lot; 
nonetheless, I find myself considering strategies that would ameliorate its 
absence.


Yea, for VOS this is pretty much essential.  Besides the fact that most 
classes in VOS are reference counted (so may be deleted anywhere), we pass 
objects like std::string around between DLLs quite a bit which of course 
does its underlying allocation on the heap.


What I've been trying to figure out is how mingw handles C runtimes.  As 
far as I can tell it links with msvcrt.dll, which I presume is the usual C 
runtime, but I've been getting these annoying SIGTRAP assertions (Invalid 
Address specified to RtlFreeHeap) that I mentioned in my previous email, 
which would suggest that it is using different heaps.  I'm so confused.


[   Peter Amstutz   ][ [EMAIL PROTECTED] ][ [EMAIL PROTECTED]  ]
[Lead Programmer][Interreality Project][Virtual Reality for the Internet]
[ VOS: Next Generation Internet Communication][ http://interreality.org ]
[ http://interreality.org/~tetron ][ pgpkey:  pgpkeys.mit.edu  18C21DF7 ]
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFDApzRaeHUyhjCHfcRAtjzAJ43hO7zh/yvSVgOeukjbDIcVRtNQgCcCLwm
8AwI0FZgJ2zpPk/yW9YDTpU=
=hf2w
-END PGP SIGNATURE-


___
vos-d mailing list
vos-d@interreality.org
http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d

Re: [vos-d] Re: struggling with Windows...

[Braden McDaniel]

res wrote:

On 16.08.2005 22:24, Braden McDaniel wrote:


Well that's annoying. So why bother with msvcr71.dll at all? Why not
just build with /MT instead and pull in the static library? What does
using the DLL runtime buy you?



Disk and RAM space savings if you have multiple modules.


 Those are not so expensive that I'd make my life much more 
difficult for the improvement. YMMV, of course.



One heap - you can free memory allocated in some other module.


That's the major selling point. Doing without this is giving up a lot; 
nonetheless, I find myself considering strategies that would ameliorate 
its absence.



And what exactly *is* annoying? Just put msvcr71.dll alongside your
application - done.


Distributing someone else's binary is annoying; establishing an 
authoritative source for it when creating a distribution on an arbitrary 
system would, I expect, be difficult. I suppose the solution to that is 
to stick it in revision control. 


But the real problem is for someone whose deliverable is a library 
rather than an application. If I want that library to be sharable by 
multiple applications, I can't very well have it depend on a library 
that Microsoft does not make sharable by multiple applications.


Braden

___
vos-d mailing list
vos-d@interreality.org
http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d

Re: [vos-d] Re: struggling with Windows...

[res]

On 16.08.2005 22:24, Braden McDaniel wrote:
> Well that's annoying. So why bother with msvcr71.dll at all? Why not
> just build with /MT instead and pull in the static library? What does
> using the DLL runtime buy you?

Disk and RAM space savings if you have multiple modules.
One heap - you can free memory allocated in some other module.

And what exactly *is* annoying? Just put msvcr71.dll alongside your
application - done.

-f.r.



signature.asc
Description: OpenPGP digital signature
___
vos-d mailing list
vos-d@interreality.org
http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d

[vos-d] Re: struggling with Windows...

[Braden McDaniel]

Hugh Perkins wrote:
msvcrt.dll is the old pre-.net  dll, msvcr71.dll is the 
.net dll


The import libraries have teh same name in each case (msvcrt.lib, 
msvcprt.lib) but point towards a differently named dll, one of those 
above, depending on the compiler version.


This, from 
, 
is noteworthy:


  What is the difference between msvcrt.dll and msvcr71.dll?

  The msvcrt.dll is now a "known DLL," meaning that it is a system
  component owned and built by Windows. It is intended for future use
  only by system-level components. An application should use and
  redistribute msvcr71.dll, and it should avoid placing a copy or using
  an existing copy of msvcr71.dll in the system directory. Instead, the
  application should keep a copy of msvcr71.dll in its application
  directory with the program executable. Any application built with
  Visual C++ .NET using the /MD switch will necessarily use msvcr71.dll.

Well that's annoying. So why bother with msvcr71.dll at all? Why not 
just build with /MT instead and pull in the static library? What does 
using the DLL runtime buy you?


Braden


___
vos-d mailing list
vos-d@interreality.org
http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d