C / C++ / MFC Discussion Boards

Rage7-Nov-07 5:22

7-Nov-07 5:22

So I have following problem (all of these are Win32 app, all MFCs, Visual 2005 applications, C++)

Application A (third-party) uses two of our dlls (which are plug-ins for A), let's say AppAplug1.dll and AppAplug2.dll. These dlls use another of our dll, Common.dll.
Version 1.0 of Common.dll is installed in AppAplug1.dll's directory, and is loaded using /DELAYLOAD by AppAplug1.dll
Version 2.1 of Common.dll is installed in AppAplug2.dll's directory, and is loaded using /DELAYLOAD by AppAplug2.dll

When I debug into AppAplug1.dll code, some function calls jumps into Common.dll Version 1 and sometimes into Common.dll Version 2.1, which brings upp following problems: some static variables are then initialised by a function call in Version 2.1, and used in Version 1, in which they are then not initilaised -> bad !

I thought processes would have their own memory space, how come I can "exchange" data like this ? How can I avoid that ?

Thanks,

~RaGE();

I think words like 'destiny' are a way of trying to find order where none exists. - Christian Graus

Do not feed the troll ! - Common proverb

Re: Dll hell

toxcct7-Nov-07 5:27

toxcct

7-Nov-07 5:27

Rage wrote:
How can I avoid that ?

can't the 2 DLLs using Common.dll use the same version, so, mount a one a only version of the DLL ?

[VisualCalc][Binary Guide][CommDialogs] | [Forums Guidelines]

Re: Dll hell

Rage7-Nov-07 5:34

Rage

7-Nov-07 5:34

Nope, because customers have different versions of the .dlls.

Plus, this would not solve the problem: I tested it with App2 using the same version of the .dll (but not the same .dll, so two .dlls in two different locations), and it failed, since App1 and App2 seem to access randomly to either the one or the other Common.dll.

C'est la merde.

~RaGE();

I think words like 'destiny' are a way of trying to find order where none exists. - Christian Graus

Do not feed the troll ! - Common proverb

Re: Dll hell

toxcct7-Nov-07 5:37

toxcct

7-Nov-07 5:37

hum, yes, i was thinking indeed to point to the same and only DLL file (by saying "version")...

Rage wrote:
C'est la merde.

bon courage, j'abdique ! lol

[VisualCalc][Binary Guide][CommDialogs] | [Forums Guidelines]

Off Topic

toxcct7-Nov-07 5:39

toxcct

7-Nov-07 5:39

Rage wrote:
Dll hell

I read this Dell Hell at first !! Laugh | :laugh:

[VisualCalc][Binary Guide][CommDialogs] | [Forums Guidelines]

Re: Off Topic

Matthew Faithfull7-Nov-07 5:58

Matthew Faithfull

7-Nov-07 5:58

Now I have a new name for our server graveyard, thanks. Big Grin | :-D

Nothing is exactly what it seems but everything with seems can be unpicked.

Re: Dll hell

Mark Salsbery7-Nov-07 7:00

Mark Salsbery

7-Nov-07 7:00

Rage wrote:
I thought processes would have their own memory space, how come I can "exchange" data like this ?

You've only mentioned one process. DLLs are not processes -
they are mapped into a process' memory space.

This is truly DLL hell, but it seems like it could have been avoided.

A true "common" dll should be just that - common. Why is there more
than one version, in more than one place?

Mark

Mark Salsbery
Microsoft MVP - Visual C++
Java | [Coffee]

Re: Dll hell

JudyL_MD7-Nov-07 10:35

JudyL_MD

7-Nov-07 10:35

Rage wrote:
I thought processes would have their own memory space, how come I can "exchange" data like this ? How can I avoid that ?

As Mark said, they do have unique memory spaces. You only have one app, therefore only one process space. Your problem is that you've managed to get two DLLs with the same names and the same entry points loaded into the same process space. What's a poor OS to do? I'm not surprised it's confused.

The "correct" solution to this is to have one and only one copy of your DLL (version 2.1) on the system (in system32 preferably) and to maintain support for version 1.0 inside your 2.1 DLL by using new names for functions that have changed or been added since 1.0. You know, like all those FunctionNameEx routines in the windows DLLs.

If you have functions with the same names that do different things in your two versions on an existing system, and the two plugin DLLs depend on the different functioning of the same-named functions and are trying to find a fix without making a coding change, IMHO you are up the proverbial creek without the proverbial paddle. You've got to resolve the ambiguity of which DLL / which function is which and I can't see a solution without a code change.

However, your third-party has obviously come across the problem and will be expecting some fix from you so you have the perfect opportunity to make that code change and fix the root issue.

Judy

Re: Dll hell

Rage7-Nov-07 21:47

Rage

7-Nov-07 21:47

Thanks.

I don't know who down-voted you; i find your comments rather accurate, and helpful.

~RaGE();

I think words like 'destiny' are a way of trying to find order where none exists. - Christian Graus

Do not feed the troll ! - Common proverb

Re: Dll hell

toxcct7-Nov-07 23:08

toxcct

7-Nov-07 23:08

just for the info, it is deprecated to put applicative DLLs into the system32 DLL. this folder is dedicated to the system itself. to place his common.dll file, he should create a common/ folder into his Program Files installation folder to place any shared components and libraries there.

[VisualCalc][Binary Guide][CommDialogs] | [Forums Guidelines]

Re: Dll hell

Nelek7-Nov-07 23:49

Nelek

7-Nov-07 23:49

I am facing now with this part of the project. I have put all the files in the same directory (there are 2 exe, 3 dll, 3 txt, 1 ini, 1 lib, 1 h) (although I think the .lib and the .h are not really needed once compiled and working)

With so few files... Should I create different directories?

Greetings.

--------
M.D.V.

If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about?

Help me to understand what I'm saying, and I'll explain it better to you

Wink | ;)

Re: Dll hell

toxcct8-Nov-07 1:45

toxcct

8-Nov-07 1:45

don't confuse the installation paths, with the source code paths.

i used to have my projects organized like this:
source files organized by separating objects layer, data access layer, computing layer and presentation layer. all these in a root folder called src/.
when i compile, the binaries are generated into a bin/ folder (at the same level that src/), and the extra lib files are written in a lib/ folder.
when i have a multiprojects solution, (mainly one or more dlls + one or more exes), i let the .h files of the dlls in their original place, and configure the dependant projects to point there.

once everything is compiled, I install my applications in program files/a_name_for_the_app/...

in the case of the OP, he as several dlls (lets say, used by several exes), which uses a common dll. he could have organized it like this :

program files/
  |_ the apps/
       |_ app1/
       |    |_ app1.exe
       |    |_ app1.dll
       |_ app2/
       |    |_ app2.exe
       |    |_ app2.dll
       |_ common/
            |_ common.dll

[VisualCalc][Binary Guide][CommDialogs] | [Forums Guidelines]

CAPICOM

Jim Crafton7-Nov-07 4:49

Jim Crafton

7-Nov-07 4:49

Does anyone know if the CAPICOM API comes default with Windows? The MSDN pages seem to say that it's part of most current Windows installs:

Redistributable	

Requires CAPICOM 2.0 or later on Windows Server 2003, Windows XP, 
Windows Me, Windows 2000 Server SP3 and later, 
Windows 2000 Professional SP3 and later, Windows NT Server 4.0 SP6a, 
and Windows 98.

Redistributable	

Requires Internet Explorer 6 SP1 or later on Windows 98.

DLL	

Requires Capicom.dll.

That would suggest, to me at least, that most computers have it. However I searched for Capicom.dll on my machine (windows XP SP2, up to date with patches) and it wasn't there.

Is this something you have to manually install?

¡El diablo está en mis pantalones! ¡Mire, mire!

Real Mentats use only 100% pure, unfooled around with Sapho Juice(tm)!

SELECT * FROM User WHERE Clue > 0
0 rows returned

Save an Orange - Use the VCF!
VCF Blog

Re: CAPICOM

led mike7-Nov-07 5:07

led mike

7-Nov-07 5:07

Jim Crafton wrote:
That would suggest, to me at least, that most computers have it.

I think it just as likely says the opposite.

Requires CAPICOM 2.0 or later on

Is saying that on those OSs [whatever] requires CAPICOM. The logical reason for saying that is because it's not there by default.

Re: CAPICOM

Jim Crafton7-Nov-07 5:36

Jim Crafton

7-Nov-07 5:36

OK. I looked a little more and it does appear that it's an optional add on. So it would appear that if you don't want to be bothered with installing anything, then you either use the .NEt API's or the raw Crypto API.

New appended menu items are disabled [modified]

followait7-Nov-07 3:49

followait

7-Nov-07 3:49

New appended menu items are disabled, though I've used MF_ENALBED.

What I want to do is like this:

Get strings from the database, then append menu items using these strings.
When I select the string in the menu, I can get the string when processing the command. In fact it is simple, but I think MFC makes it harder. Any easy way there? Thanks very much.

-- modified at 20:05 Wednesday 7th November, 2007

Re: New appended menu items are disabled

led mike7-Nov-07 4:19

led mike

7-Nov-07 4:19

followait wrote:
though I've used MF_ENALBED

how? We don't know what you did if you don't post some relevant code.

followait wrote:
Any easy way there?

I have no idea what you would consider "easier" ... maybe this [^]that I found hidden in the documentation

Re: New appended menu items are disabled

David Crow7-Nov-07 4:26

David Crow

7-Nov-07 4:26

led mike wrote:
I have no idea what you would consider "easier" ... maybe this [^]that I found hidden in the documentation

Yeah, but that's not fair, Mike. You actually had to search for that, which takes time and effort. Hardly something that is considered easy.

"Normal is getting dressed in clothes that you buy for work and driving through traffic in a car that you are still paying for, in order to get to the job you need to pay for the clothes and the car and the house you leave vacant all day so you can afford to live in it." - Ellen Goodman

"To have a respect for ourselves guides our morals; to have deference for others governs our manners." - Laurence Sterne

Re: New appended menu items are disabled

led mike7-Nov-07 5:04

led mike

7-Nov-07 5:04