DLL如何编译？

>我可以查看dll的源代码。至少这是有用的。
一件简单的事情就是计算所有malloc和free调用，或GlobalAlloc和GlobalFree，或任何使用todo内存管理的调用......无论如何，总数应该是偶数。
更具体地说，每个分配都应该是免费的。
如果没有，那么*可能*是问题。> Headerfile：K。
除了pRxStr之外，我没有看到任何直接表明问题的信息。
这是一个out指针 - 一个指向字符串指针的指针 - 实际上我印象深刻，你可以使用它。这样的事情的通常情况是，dll为返回的字符串分配了足够的内存，并在传递的地址中填充指针 -
指向字符串指针的指针。
dll假设调用者对内存不满意。如果是这样，那么你是对的。
这就是你的问题所在。
VEE不会释放外部分配的内存。
至少我很确定。
它可能，但对细节的那种关注将超过CFI设计者的调用，并依赖于它可能是愚蠢的。实际上，它会将其解释为指向字符串数组的指针。
itworks有点令人惊讶 - 如果返回的字符串是16bytes长的倍数，你可能会遇到问题（VEE可能看不到属性）。
如果你不必使用数组符号来获得返回的字符串我很惊讶：有人正在表演某种魔法，我很想知道它是什么。无论如何，要确定这是否是一个问题，请检查
源代码是这样的：* pRxStr = malloc（lstrlen（pSomething））;或* pRxStr = malloc（iRxStrLen）; malloc可以是GlobalAlloc，LocalAlloc或HeapAlloc。
如果你发现它，那肯定是个问题。
解决方案相对简单，虽然它会带来一些编程麻烦。
它可以使用straightVEE或包装器dll来完成。当然，dll文档应该确切地说明如何处理它。
可能是它专门设计用于VEE，并且它将pRxStr解释为先前分配的字符串数组，但这看起来不太可能。
函数也可能需要指向先前分配的单个缓冲区的指针（在COM API注释中很常见，例如LPVOID * ppv - 请参阅CoCreateInstance）。
这似乎也不太可能。-SHAWN ----您目前订阅vrf为：r***@soco.agilent.com要订阅，请发送空白电子邮件至“join-vrf@it.lists.it.agilent.com”
。要取消订阅，请发送空白电子邮件至“leave-vrf@it.lists.it.agilent.com”。要向此邮件列表发送邮件，请发送电子邮件至“vrf@agilent.com”。
如果您需要有关邮件列表的帮助，请发送邮件至“owner-vrf@it.lists.it.agilent.com”。



     以下为原文

  > I can view the source code for the dll.

At least that's helpful. One easy thing to do is count up all the malloc and
free calls, or GlobalAlloc and GlobalFree, or whatever calls it's using to
do memory management... at any rate, the total should be even. More
specifically for each alloc there should be a free. If not, then it *may* be
a problem.

> Headerfile:

K. I don't see anything that is immediately indicative of a problem except
pRxStr. This is an out pointer - a pointer to a string pointer - and
actually I'm impressed you can use this.

The usual scenario with stuff like this is that the dll allocates enough
memory for the returned string and stuffs the pointer to it in the passed
address - a pointer to a string pointer. The dll assumes that the caller
frees the memory.

If that's the case, then you're right. That's where your problem is. VEE
will not free externally allocated memory. At least I'm pretty sure it
won't. It might, but that kind of attention to detail would be over and
above the call on the part of the CFI designers and to depend on it would
probably be foolish.

In fact, it will interpret this as a pointer to a string array. That it
works is somewhat surprising - if the returned string is a multiple of 16
bytes long you might run into problems with this (VEE might not see proper
termination). If you don't have to use array notation to get at the returned
string I'm amazed: somebody is performing some kind of magic and I'd love to
know what it is.

At any rate, to determine if this is a problem, check the source code for
something like this:

*pRxStr = malloc(lstrlen(pSomething));
or
*pRxStr = malloc(iRxStrLen);

The malloc may be GlobalAlloc, LocalAlloc or HeapAlloc. If you find it, then
that is definitely a problem. The solution is relatively simple though it
will take a bit of programming hassle. It can be done either with straight
VEE or a wrapper dll.

Of course the dll documentation should say exactly how to handle it. It
could be that it was designed specifically for use with VEE and it does
interpret pRxStr as a previously allocated string array, but that doesn't
seem likely. It's also possible that the function expects a pointer to a
previously allocated single buffer (as is common in the COM API with
notation such as LPVOID *ppv - see CoCreateInstance). That doesn't seem very
likely either.
-SHAWN-


---
You are currently subscribed to vrf as: [email=r***@soco.agilent.com]r***@soco.agilent.com[/email]
To subscribe send a blank email to "join-vrf@it.lists.it.agilent.com".
To unsubscribe send a blank email to "leave-vrf@it.lists.it.agilent.com".
To send messages to this mailing list,  email "vrf@agilent.com". 
If you need help with the mailing list send a message to "owner-vrf@it.lists.it.agilent.com".

Shawn，DLL是如何编译的？
如果使用MS Windows VS，那么可以添加一些东西，否则，'可能想要重新编译并包含来自.NET.Rufus的一些有用的“东西”-----原始消息-----来自：Shawn Fessenden [
mailto：shawn@testech-ltd.com]发送：2005年1月6日星期四6:42 AMTo：VRFS主题：[vrf] RE：Memory Eater ... dll问题>我可以查看dll的源代码。至少
这很有帮助。
一件简单的事情就是计算所有malloc和free调用，或GlobalAlloc和GlobalFree，或任何使用todo内存管理的调用......无论如何，总数应该是偶数。
更具体地说，每个分配都应该是免费的。
如果没有，那么*可能*是问题。> Headerfile：K。
除了pRxStr之外，我没有看到任何直接表明问题的信息。
这是一个out指针 - 一个指向字符串指针的指针 - 实际上我印象深刻，你可以使用它。这样的东西的通常情况是，dll为返回的字符串分配了足够的内存，并在传递的地址中填充指针 -
指向字符串指针的指针。
dll假设调用者对内存不满意。如果是这样，那么你是对的。
这就是你的问题所在。
VEE不会释放外部分配的内存。
至少我很确定。
它可能，但对细节的那种关注将超过CFI设计者的调用，并依赖于它可能是愚蠢的。实际上，它会将其解释为指向字符串数组的指针。
itworks有点令人惊讶 - 如果返回的字符串是16bytes长的倍数，你可能会遇到问题（VEE可能看不到属性）。
如果你不必使用数组符号来获得返回的字符串我很惊讶：有人正在表演某种魔法，我很想知道它是什么。无论如何，要确定这是否是一个问题，请检查
源代码是这样的：* pRxStr = malloc（lstrlen（pSomething））;或* pRxStr = malloc（iRxStrLen）; malloc可以是GlobalAlloc，LocalAlloc或HeapAlloc。
如果你发现它，那肯定是个问题。
解决方案相对简单，虽然它会带来一些编程麻烦。
它可以使用straightVEE或包装器dll来完成。当然，dll文档应该确切地说明如何处理它。
可能是它专门设计用于VEE，并且它将pRxStr解释为先前分配的字符串数组，但这看起来不太可能。
函数也可能需要指向先前分配的单个缓冲区的指针（在COM API注释中很常见，例如LPVOID * ppv - 请参阅CoCreateInstance）。
这似乎也不太可能。-SHAWN ----您目前订阅了vrf：rwarren@amti.net订阅发送ablank电子邮件至“join-vrf@it.lists.it.agilent.com”.To
取消订阅会发送一封空白电子邮件至“leave-vrf@it.lists.it.agilent.com”。要向此邮件列表发送邮件，请发送电子邮件至“vrf@agilent.com”。
如果您需要有关邮件列表的帮助，请发送邮件至“owner-vrf@it.lists.it.agilent.com”.---您目前订阅vrf为：r***@soco.agilent.com要订阅发送空白
发送电子邮件至“join-vrf@it.lists.it.agilent.com”。要取消订阅，请发送一封空白电子邮件至“leave-vrf@it.lists.it.agilent.com”。要向此邮件列表发送邮件，请发送电子邮件至
“vrf@agilent.com”。
如果您需要有关邮件列表的帮助，请发送邮件至“owner-vrf@it.lists.it.agilent.com”。



     以下为原文

  Shawn,

How is the DLL compiled?  If using MS Windows VS, then there exist some
things that can be added, else, ' might want to recompile and include some
useful "stuff" from .NET.


Rufus

-----Original Message-----
From: Shawn Fessenden [mailto:shawn@testech-ltd.com]
Sent: Thursday, January 06, 2005 6:42 AM
To: VRF
Subject: [vrf] RE: Memory Eater...dll problems

> I can view the source code for the dll.

At least that's helpful. One easy thing to do is count up all the malloc and
free calls, or GlobalAlloc and GlobalFree, or whatever calls it's using to
do memory management... at any rate, the total should be even. More
specifically for each alloc there should be a free. If not, then it *may* be
a problem.

> Headerfile:

K. I don't see anything that is immediately indicative of a problem except
pRxStr. This is an out pointer - a pointer to a string pointer - and
actually I'm impressed you can use this.

The usual scenario with stuff like this is that the dll allocates enough
memory for the returned string and stuffs the pointer to it in the passed
address - a pointer to a string pointer. The dll assumes that the caller
frees the memory.

If that's the case, then you're right. That's where your problem is. VEE
will not free externally allocated memory. At least I'm pretty sure it
won't. It might, but that kind of attention to detail would be over and
above the call on the part of the CFI designers and to depend on it would
probably be foolish.

In fact, it will interpret this as a pointer to a string array. That it
works is somewhat surprising - if the returned string is a multiple of 16
bytes long you might run into problems with this (VEE might not see proper
termination). If you don't have to use array notation to get at the returned
string I'm amazed: somebody is performing some kind of magic and I'd love to
know what it is.

At any rate, to determine if this is a problem, check the source code for
something like this:

*pRxStr = malloc(lstrlen(pSomething));
or
*pRxStr = malloc(iRxStrLen);

The malloc may be GlobalAlloc, LocalAlloc or HeapAlloc. If you find it, then
that is definitely a problem. The solution is relatively simple though it
will take a bit of programming hassle. It can be done either with straight
VEE or a wrapper dll.

Of course the dll documentation should say exactly how to handle it. It
could be that it was designed specifically for use with VEE and it does
interpret pRxStr as a previously allocated string array, but that doesn't
seem likely. It's also possible that the function expects a pointer to a
previously allocated single buffer (as is common in the COM API with
notation such as LPVOID *ppv - see CoCreateInstance). That doesn't seem very
likely either.
-SHAWN-


---
You are currently subscribed to vrf as: rwarren@amti.net To subscribe send a
blank email to "join-vrf@it.lists.it.agilent.com".
To unsubscribe send a blank email to "leave-vrf@it.lists.it.agilent.com".
To send messages to this mailing list,  email "vrf@agilent.com". 
If you need help with the mailing list send a message to
"owner-vrf@it.lists.it.agilent.com".


---
You are currently subscribed to vrf as: [email=r***@soco.agilent.com]r***@soco.agilent.com[/email]
To subscribe send a blank email to "join-vrf@it.lists.it.agilent.com".
To unsubscribe send a blank email to "leave-vrf@it.lists.it.agilent.com".
To send messages to this mailing list,  email "vrf@agilent.com". 
If you need help with the mailing list send a message to "owner-vrf@it.lists.it.agilent.com".