[comp.windows.ms.programmer] BC++ Classes having duplicate execution problem'

mwizard@eecs.cs.pdx.edu (Craig Nelson) (05/26/91)

Hope this is the right group to post this to.  Just got BC++ about
a week ago, and it's a real kick.  I also received some two weeks
before a copy of Borland Language Express, in which several rather
general windows classes are listed.   I used these classes to write
a couple of do-nothing test programs, and here's where things get a
little weird.

	Call the first program hello1, the second hello2. Both are
seperate windows programs using the same class library (which is NOT
in a DLL).  I execute hello1, and all is well.   Then I execute hello2,
and again, all is well.  Now, if I execute hello2, then try to execute
hello1, I get another copy of hello2 on the screen.  Another interesting
point.  If I load hello2, then load TDW, then attempt to load hello1 in
the debugger it won't load.  Says somthings about an error loading file.
Now if I then quit the running version of hello2, then reload the debugger,
then ask to load hello1 in the debugger, it works and all is fine.

My question is simple.  How does Windows start up the same program from an
entirely different executable, with only the linked libraries in common ?
Better question: Why ???.  One more question:  Anyone got a solution to
this problem ?

Just occured to me that many might not have the code in BLXpress to look
over and ponder this problem.  Since it's available via Borlands download
BBS, I don't think they'd mind me giving it to all who would like it.

Thanks for any help you can give me.

Cheers

Craig.

risto@tuura.UUCP (Risto Lankinen) (05/27/91)

mwizard@eecs.cs.pdx.edu (Craig Nelson) writes:

>My question is simple.  How does Windows start up the same program from an
>entirely different executable, with only the linked libraries in common ?

Hi!

Check the 'NAME <appname>' field of each program's linker definition file.
You should use an <appname> that corresponds the executable file name of
the resulting program.  Also, you cannot use the same <filename>.EXE for
both programs, even if they stayed put in different directories.

Why?  The Windows uses both the executable file name and the 'NAME'-field
of the linker definition, to decide from where (if at all) to reload a new
application (or a segment in an already loaded application).  Thus, at any
moment in a Windows system there should be loaded only such modules, which
have both <filename> and <appname> unique.

Terveisin: Risto Lankinen
-- 
Risto Lankinen / product specialist ***************************************
Nokia Data Systems, Technology Dept *  2                              3   *
THIS SPACE INTENTIONALLY LEFT BLANK * 2 +1 is PRIME!  Now working on 2 -1 *
replies: risto@yj.data.nokia.fi     ***************************************

Risto.Lankinen@sunbrk.FidoNet.Org (Risto Lankinen) (05/27/91)

mwizard@eecs.cs.pdx.edu (Craig Nelson) writes:

>My question is simple.  How does Windows start up the same program from an
>entirely different executable, with only the linked libraries in common ?

Hi!

Check the 'NAME <appname>' field of each program's linker definition file.
You should use an <appname> that corresponds the executable file name of
the resulting program.  Also, you cannot use the same <filename>.EXE for
both programs, even if they stayed put in different directories.

Why?  The Windows uses both the executable file name and the 'NAME'-field
of the linker definition, to decide from where (if at all) to reload a new
application (or a segment in an already loaded application).  Thus, at any
moment in a Windows system there should be loaded only such modules, which
have both <filename> and <appname> unique.

Terveisin: Risto Lankinen
-- 
Risto Lankinen / product specialist ***************************************
Nokia Data Systems, Technology Dept *  2                              3   *
THIS SPACE INTENTIONALLY LEFT BLANK * 2 +1 is PRIME!  Now working on 2 -1 *
replies: risto@yj.data.nokia.fi     ***************************************

 * Origin: Seaeast - Fidonet<->Usenet Gateway - sunbrk (1:343/15.0)