Re: Dll Hell

On Sat, 25 Mar 2006 09:23:40 UTC, "Mat Nieuwenhoven"
<mnieuw@xxxxxxxxxxxxxxxxxxxxxxxxxxxx> wrote:

On Sat, 25 Mar 2006 00:15:35 -0000, Paul Smedley wrote:

<snip>

:>I assume I'm the PAUL you're mentioning above..... Care to point out
:>the installer I ship that puts dll's into \os2\dll? The only thing I
:>ship with an installer is tame, and it puts usbcalls.dll and
:>libc06*.dll into the Tame directory.
:>
:>There is no way I'm going to ship libc*.dll in all of my packages -
:>you realise that would add 600k+ to the archive and in most cases
:>would be a waste of time as people would already have it. Not
:>everyone has a . in their libpath. All my packages clearly point out
:>where to download the gcc runtime. Given the number of applications
:>that use gcc - IMHO the best place to put the DLL is somewhere in the
:>libpath (note eCS puts various libc runtimes into x:\ecs\dll).

Paul, many thanks for all the ports you're doing. I don't know if it is
possible with GCC to link statically, but that would eliminate the DLL
problems. This is of course only feasible if the linker is smart enough to
link in only those parts of glib that are actually used.....


DLLs are created to share code between applications and to short used
memory to a minimum. It makes really no sense to have 100 times load
exactly the same code to blow up memory to 10 TB in use while having
the same code shared in 10 DLLs reducing that to 1 GB.

Will you be so kindly and would replace the OS/2 memory manager to be
able to handle an addressspace of 400 TB instead of only 4GB? Then you
may bind each and anything statically and produce applications of 4 GB
in size to get them independant from dynamically bounded libraries.

Look on what memory monsters GCC, LIBC and so on are. Don't think that
C++ applications without shared DLLs will shrink in theyr binary size.

Does you really mean that anybody on the world has now a DSL flatrate
an can download terabytes quickly? There are some regions where an 22K
modem is the most available download sped.

I'm happy to have an OS that runs with only 256 MB RAM with 100%
unused swapper space smoothly instead to force to upgrade to 4GB only
to get 30 apps active in parallel and 2 GB swapper.

It would be nice anyway to have an install manager who is able to
upgrade DDLs and applications from external source (e.g. internet or
local archives) when they are coming up with newer versions. But don't
think that such job would be easy.

--
Tschau/Bye
Herbert

Visit http://www.ecomstation.de the home of german eComStation
eComStation 1.2 Deutsch ist da!
.

Relevant Pages

  • Re: Dll Hell
    ... The only thing I:>ship with an installer is tame, and it puts usbcalls.dll and:>libc06*.dll into the Tame directory. ... DLLs are created to share code between applications and to short used memory to a minimum. ... It makes really no sense to have 100 times load exactly the same code to blow up memory to 10 TB in use while having the same code shared in 10 DLLs reducing that to 1 GB. ...
    (comp.os.os2.apps)
  • Re: Looking for an Application Launcher in W2K3 SBS
    ... >> can manage 1000 of things regarding to applications and shortcuts... ... >>> Thank you for posting to the SBS Newsgroup. ... >>> I understand that you want to know how to deploy applications to client ... >>> the client and to launch the application installer from the client. ...
    (microsoft.public.windows.server.sbs)
  • Re: ruby tk -- how do you get it working?
    ... dir containing the file is examined to determine if it is now empty. ... Ruby One-Click Installer for OSX Tiger.pkg ... puts <<STR ... fname = nil ...
    (comp.lang.ruby)
  • Re: Internationalization
    ... necessarily the DLLs, but the way in which the assumption about one-DLL-fits-all solution ... security guy wanting to know what this DLL was, and why it had to be in system32 (the ... answer was that it didn't need to be, but it wasn't our installer that installed it, it ... Laermans (a Product Unit Manager at Microsoft) at the last MVP Summit how ...
    (microsoft.public.vc.mfc)
  • Re: Deployment Question
    ... >> applications that use those core DLLs. ... >> .DLLs in the system folder and just share them between the two ... I would go ahead with the simple XCopy deployment. ...
    (microsoft.public.vstudio.general)