Binary Compatibility Question

We have an application that was written using VS6. It uses a number of DLL
type extensions and we need to write a new extension. We no longer support
VS 6 in our development lab and would like to know if a DLL (written in "C")
and built in VS.NET 2003 will be compatible with the VS application.

Thanks,
Sid.

--
Sid Price's Software Tools.
http://www.Softtools.com

Victor
Fri May 06 14:55:11 CDT 2005

Sid Price wrote:
> We have an application that was written using VS6. It uses a number of DLL
> type extensions and we need to write a new extension. We no longer support
> VS 6 in our development lab and would like to know if a DLL (written in "C")
> and built in VS.NET 2003 will be compatible with the VS application.

It may be. Or it may not be. You need to be careful when exporting stuff
from your DLL and making use of other DLLs (like C run-time).

V

Sid
Fri May 06 15:05:18 CDT 2005

I don't understand what you are suggesting. The interface to call the DLL
should be fixed and if the DLL links to an older C run-time then that will
need to be distributed but the interface into/out of the run-time will be
unchanged.

What issues are you anticipating?

Sid.

--
Sid Price's Software Tools.
http://www.Softtools.com

"Victor Bazarov" <v.Abazarov@comAcast.net> wrote in message
news:u0AiEWnUFHA.3544@TK2MSFTNGP12.phx.gbl...
> Sid Price wrote:
>> We have an application that was written using VS6. It uses a number of
>> DLL type extensions and we need to write a new extension. We no longer
>> support VS 6 in our development lab and would like to know if a DLL
>> (written in "C") and built in VS.NET 2003 will be compatible with the VS
>> application.
>
> It may be. Or it may not be. You need to be careful when exporting stuff
> from your DLL and making use of other DLLs (like C run-time).
>
> V

Victor
Fri May 06 15:17:09 CDT 2005

Sid Price wrote:
> I don't understand what you are suggesting. The interface to call the DLL
> should be fixed and if the DLL links to an older C run-time then that will
> need to be distributed but the interface into/out of the run-time will be
> unchanged.
>
> What issues are you anticipating?

(a) Please don't top-post.

(b) If the memory is allocated in one run-time and an attempt is made
to free it using another run-time, it would be inconsequential that
you ship them both along with your executable. You still may have
deallocation problems (up to crashes) on your hands. And that's
the most common problem. I'll let others give more exotic examples.

V

Sid
Fri May 06 15:23:25 CDT 2005

a) I always top-post - get over it!

b) If I understand your memory allocation concern, it would not be an issue
provided that all memory allocated within the DLL (or in a run-time call by
the DLL) was freed in the DLL or the run-time to which it linked. Is that
correct?

Thanks,
Sid.
--
Sid Price's Software Tools.
http://www.Softtools.com

"Victor Bazarov" <v.Abazarov@comAcast.net> wrote in message
news:eIReWinUFHA.3076@TK2MSFTNGP12.phx.gbl...
> Sid Price wrote:
>> I don't understand what you are suggesting. The interface to call the DLL
>> should be fixed and if the DLL links to an older C run-time then that
>> will need to be distributed but the interface into/out of the run-time
>> will be unchanged.
>>
>> What issues are you anticipating?
>
> (a) Please don't top-post.
>
> (b) If the memory is allocated in one run-time and an attempt is made
> to free it using another run-time, it would be inconsequential that
> you ship them both along with your executable. You still may have
> deallocation problems (up to crashes) on your hands. And that's
> the most common problem. I'll let others give more exotic examples.
>
> V

beginthreadex
Fri May 06 15:51:06 CDT 2005

what's "top-post"-ing?

Victor Bazarov wrote:

> Sid Price wrote:
>> I don't understand what you are suggesting. The interface to call the DLL
>> should be fixed and if the DLL links to an older C run-time then that
>> will need to be distributed but the interface into/out of the run-time
>> will be unchanged.
>>
>> What issues are you anticipating?
>
> (a) Please don't top-post.
>
> (b) If the memory is allocated in one run-time and an attempt is made
> to free it using another run-time, it would be inconsequential that
> you ship them both along with your executable. You still may have
> deallocation problems (up to crashes) on your hands. And that's
> the most common problem. I'll let others give more exotic examples.
>
> V

--
new

Eugene
Fri May 06 17:28:03 CDT 2005

Sid Price wrote:
> b) If I understand your memory allocation concern, it would not be an
> issue provided that all memory allocated within the DLL (or in a
> run-time call by the DLL) was freed in the DLL or the run-time to
> which it linked. Is that correct?

Yes.
In more general terms you are not allowed to share anything that relies on
CRT state across modules that use different CRTs. So you cannot free() what
was malloc()-ed in another dll, you cannot pass FILE * from or to DLL,
various set_xxx and get_xxx functions that inspect and modify CRT state will
usually not affect each other if called in different modules etc. Anything
you do with such stuff should stay within one module.
Then there are also additional concerns if you use C++ as opposed to C but
since you say that your DLL is written in C this shouldn't be a problem.


--
Eugene
http://www.gershnik.com

Sid
Fri May 06 18:26:12 CDT 2005

Thanks,
Sid.

--
Sid Price's Software Tools.
http://www.Softtools.com

"Eugene Gershnik" <gershnik@hotmail.com> wrote in message
news:Ol9SdroUFHA.3532@TK2MSFTNGP09.phx.gbl...
> Sid Price wrote:
>> b) If I understand your memory allocation concern, it would not be an
>> issue provided that all memory allocated within the DLL (or in a
>> run-time call by the DLL) was freed in the DLL or the run-time to
>> which it linked. Is that correct?
>
> Yes.
> In more general terms you are not allowed to share anything that relies on
> CRT state across modules that use different CRTs. So you cannot free()
> what was malloc()-ed in another dll, you cannot pass FILE * from or to
> DLL, various set_xxx and get_xxx functions that inspect and modify CRT
> state will usually not affect each other if called in different modules
> etc. Anything you do with such stuff should stay within one module.
> Then there are also additional concerns if you use C++ as opposed to C but
> since you say that your DLL is written in C this shouldn't be a problem.
>
>
> --
> Eugene
> http://www.gershnik.com
>
>
>

John
Fri May 06 18:45:40 CDT 2005

"beginthreadex" <beginthreadex@hotmail.com> wrote in message
news:%23s$NU4nUFHA.3280@TK2MSFTNGP10.phx.gbl
> what's "top-post"-ing?

Making your comments at the top of the quoted message.
--
John Carson