[gmpi] Re: Reqs draft
- From: Paul Davis <paul@xxxxxxxxxxxxxxxxxxxxx>
- To: gmpi@xxxxxxxxxxxxx
- Date: Sun, 09 Nov 2003 11:54:34 -0500
>> ah, this is the core of the speed concerns, eh? so, to handle the
>> paranoia (somewhat justified paranoia :) of proprietary developers,
>
>You have maybe the change to stay alive without saling any software , this
>is not my case , sorry.
not the right forum for this discussion, alas.
>> we have to introduce the inevitable problems that occur when you use an
>> external registry to maintain information. i have never heard of *any*
>> system that does this without problems. what happens on systems that
>> have both "system wide" plugins and "per-user" plugins? where is the
>> registry? how does the information get stored without collisions if
>> the user updates their personal copy of FooMatic, but the system still
>> has the older one installed? are there N registries? how are they
>discovered?
>
>What are you talking about !?.
most modern OS's are multi-user systems. i might want to install
plugins on a system where i do not have "administrator/root/superuser"
access. so i put them somewhere that belongs to me. this is standard
practice for every program i've ever seen that uses plugins of any
kind. the host searches multiple locations to find plugins ...
now, if you can guarantee that "Foomatic v1.2" and "Foomatic v1.3"
always show up with names like that, OK, but last time i looked, all
the hosts i've seen don't show version numbers of plugins. So what is
a user to think when the list shows "Foomatic" and "Foomatic" ? which
is which?
>if you prefer that why not, personnally i prefer to deal with a central
>datafile, with access function provided by GMPI to register the plug-in and
>information in.
what calls the function? the plugin? when? how does it get write
permission to the database? on multi-user systems you don't have
permission to write to system-wide files unless the program being
executed has been given special priviledges. which program is that?
nuendo?
>> AFAIK, all modern operating systems (windows included) do not allocate
>> memory for the data sections of a DLL until the relevant addresses are
>> touched. they *might* (if implemented badly) have to read the data
>> sections while loading, but it doesn't get loaded into memory at that
>> time.
>
>Sorry Paul, you are too much in the theoritical aspect, if you load a DLL,
>it is to put it in memory , otherwise why loading a DLL !? well, If you
virtual memory. did you not study modern operating system design at
some point? allocating an address range in virtual memory has nothing
whatsoever to do with allocating physical RAM. huge chunks of
creativity have gone into the OS code that is responsible for creating
and maintaining the mapping between the two. when you load a DLL, the
run time linker reads the object file, discovers which sections in
exist, loads some of them, and maps others into the address
space. typically, anyway.
>load all your VST's plug-in on your system without using memory, let us know
>the method :-)
there is no method. and i didn't say "no memory". i said that pages of
data that are not touched do not occupy physical RAM. as soon as you
touch them, the OS has to allocate physical RAM, bring the data from
disk into memory, and map the physical RAM into the virtual address
space. this is all basic modern OS stuff. even windows has done this
for some time (after they adopted the NT kernel, anyway).
for a different approach to understanding this, when your application
is linked against the C run time, do you think you application
automatically loads the entire C run time into memory at start time?
no, it maps the C run time into its address space, and as it accesses
various parts of the C run time, just those parts get loaded into
memory as needed.
typically for a DLL, all the code is likely to be loaded into physical
RAM (though not necessarily), and the data section(s) are left mapped
but not loaded till they are accessed by the execution context.
if you don't understand this, just say so. if you haven't studied OS
design and virtual memory, it can be confusing - i know it was to me
when i first ran into this stuff.
--p
----------------------------------------------------------------------
Generalized Music Plugin Interface (GMPI) public discussion list
Participation in this list is contingent upon your abiding by the
following rules: Please stay on topic. You are responsible for your own
words. Please respect your fellow subscribers. Please do not
redistribute anyone else's words without their permission.
Archive: //www.freelists.org/archives/gmpi
Email gmpi-request@xxxxxxxxxxxxx w/ subject "unsubscribe" to unsubscribe
Other related posts:
