Is a DLL the best approach? 
Author Message
 Is a DLL the best approach?

I am not familiar with DLL's and would like to know if the following idea
makes sense.

THE SITUATION

I am developing an MFC application using VC++.NET that is intended to run
under Windows 2000.  I am responsible for everything EXCEPT the decision
making part of the program.  In other words, I'll be doing all the user
interfacing, system interfacing and hardware interfacing while a co-worker
is responsible for the decision making part of the system.  The interface
with my co-worker is pretty much under my control.  The decision making
process requires perhaps 50 or 100K bytes of input data and returns less
than 1K of output data.  The decision making process is not time critical
but fast responses are desirable and more than a couple seconds would be
unacceptable.  (In other words, the interface between me and the decision
making process can not be TOO slow.)

My portion of the job is well bounded and will likely be completed in about
a year and a half (after about the third customer site).  My co-workers
portion of the job is unbounded and he is expected to be extending and
refining things for at least the next five years and, if things go well,
perhaps as much as ten years.

My co-worker will be doing all of his work in C using a Borland compiler.
He would prefer to run under either Windows 98 or DOS.  If necessary, I
could probably force him to upgrade to Windows 2000.

THE PROBLEM

Management believes that he is going to build/test his decision making code
independently and that I will 'snapshot' the source, modify it as necessary
for VC++.NET, combine it with my project and crank out the corresponding
.EXE for each customer.  This will work fine for the first few customers but
will soon become unwieldy as the customer/customer revision tree grows and
grows.  Even worse, this approach keeps me tied to this job for the next
five to ten years in an administrative role while all of my engineering is
finished in the first year and a half.

THE IDEA

I would like to believe that I could structure my application such that the
decision making process was a DLL.  I would also like to believe that my
co-worker could produce compatible DLL's within the limits mention above.  I
accept that I may have to provide my co-worker with a basic DLL structure
into which he could drop his C code.  Once my application was complete, my
co-worker could continue to extend his portion of the job without requiring
knowledge of C++, VC++ or MFC.

Does this make sense?  What should I look at/read to (relatively quickly)
get up to speed with what I need to know about DLL's.  Thanks for any
assistance.

DISCLAIMER

If you have other suggestions about what I should do, please don't hesitate.
However, please resist the urge to include solutions centered around
radically changing what my co-worker does.  The situation is what it is.I am
just trying to make the best of what I have to work with.  Thanks.



Mon, 26 Sep 2005 22:04:11 GMT  
 Is a DLL the best approach?
Given what you've outlined, yes, I think a DLL interface makes sense.

And yes, you can provide a shell that he can use with Borland C++ under
Windoze 98 to generate a DLL that you can call from your MFC app on Win2000.

Basically, what you need to do is specify an interface that:
1. Uses only built-in C types and POD structs (no classes).
2. Clearly defines ownership responsibilities for all data passed through
the interface.  For example, if the DLL returns an allocated resource (e.g.
memory) to you, then the DLL must also expose a function for reclamation of
that resource.
3. Use a .DEF file to explicitly name all of the exports from the DLL.  This
avoids different name decoration standards for the compilers.
4. Make all DLL entry points use the stdcall calling convention.  This
calling convention is required by the Windows ABI (applicaiton binary
interface), and so must be supported identically by all Windows compatible
toolchains.

You might want to use LoadLibrary/GetProcAddress to link your code to the
DLL rather than using an import library.  Using LoadLibrary allows the name
of the DLL to be determined at runtime, which sounds like it might be
helpful.

Further, I'd recommend writing a C++ class that completely wraps the DLL
interface in a suitably designed class interface, and that encapsulates all
resource allocation/reclamation protocols used with the DLL.  The end result
should be an easy to use class with dynamically pluggable functionality.

I've successfully used these techniques many times, with VC6 compiled EXEs
hosting plug-ins compiled with VC7, VC7.1, BC5, and other compilers.

If you'd like more details, reply here, or feel free to email me (remove
nospam from the reply address) and I'll do what I can to help.

-cd

Quote:

> I am not familiar with DLL's and would like to know if the following
> idea makes sense.

> THE SITUATION

> I am developing an MFC application using VC++.NET that is intended to
> run under Windows 2000.  I am responsible for everything EXCEPT the
> decision making part of the program.  In other words, I'll be doing
> all the user interfacing, system interfacing and hardware interfacing
> while a co-worker is responsible for the decision making part of the
> system.  The interface with my co-worker is pretty much under my
> control.  The decision making process requires perhaps 50 or 100K
> bytes of input data and returns less than 1K of output data.  The
> decision making process is not time critical but fast responses are
> desirable and more than a couple seconds would be unacceptable.  (In
> other words, the interface between me and the decision making process
> can not be TOO slow.)

> My portion of the job is well bounded and will likely be completed in
> about a year and a half (after about the third customer site).  My
> co-workers portion of the job is unbounded and he is expected to be
> extending and refining things for at least the next five years and,
> if things go well, perhaps as much as ten years.

> My co-worker will be doing all of his work in C using a Borland
> compiler. He would prefer to run under either Windows 98 or DOS.  If
> necessary, I could probably force him to upgrade to Windows 2000.

> THE PROBLEM

> Management believes that he is going to build/test his decision
> making code independently and that I will 'snapshot' the source,
> modify it as necessary for VC++.NET, combine it with my project and
> crank out the corresponding .EXE for each customer.  This will work
> fine for the first few customers but will soon become unwieldy as the
> customer/customer revision tree grows and grows.  Even worse, this
> approach keeps me tied to this job for the next five to ten years in
> an administrative role while all of my engineering is finished in the
> first year and a half.

> THE IDEA

> I would like to believe that I could structure my application such
> that the decision making process was a DLL.  I would also like to
> believe that my co-worker could produce compatible DLL's within the
> limits mention above.  I accept that I may have to provide my
> co-worker with a basic DLL structure into which he could drop his C
> code.  Once my application was complete, my co-worker could continue
> to extend his portion of the job without requiring knowledge of C++,
> VC++ or MFC.

> Does this make sense?  What should I look at/read to (relatively
> quickly) get up to speed with what I need to know about DLL's.
> Thanks for any assistance.

> DISCLAIMER

> If you have other suggestions about what I should do, please don't
> hesitate. However, please resist the urge to include solutions
> centered around radically changing what my co-worker does.  The
> situation is what it is.I am just trying to make the best of what I
> have to work with.  Thanks.



Tue, 27 Sep 2005 00:55:41 GMT  
 
 [ 2 post ] 

 Relevant Pages 

1. Best approach - Opinons?

2. Good design approach?

3. Best approach??

4. Curious about better approaches ...

5. Best approach for comparing numbers

6. best mulithreading approach?

7. What is the best approach ???

8. Best approach for multithreading a batch process??

9. Best Approach...???

10. Best approach to text searching (keywords)?

11. Best Approach For Establishing a Modem Connection

12. Best approach to text searching (keywords)?

 

 
Powered by phpBB® Forum Software