Anyone have a DLL with a function to dereference memory addresses?

[Aristos Queue]

Does anyone have a standalone DLL that has a function which, given a memory address, returns the byte, word or int at that memory address? It would be useful for a hack I'm contemplating, and I don't feel like coding a DLL for a one-off project.

[Chris Davis]

QUOTE(Aristos Queue @ Jul 20 2007, 02:42 PM)

Does anyone have a standalone DLL that has a function which, given a memory address, returns the byte, word or int at that memory address? It would be useful for a hack I'm contemplating, and I don't feel like coding a DLL for a one-off project.

IMAQ Mempeek should do what you want, or you can check this thread to find other ways.

[Aristos Queue]

QUOTE(chrisdavis @ Jul 20 2007, 03:51 PM)

IMAQ Mempeek should do what you want, or you can check this thread to find other ways.

Thanks.

[Rolf Kalbermatter]

QUOTE(Aristos Queue @ Jul 20 2007, 02:42 PM)

Does anyone have a standalone DLL that has a function which, given a memory address, returns the byte, word or int at that memory address? It would be useful for a hack I'm contemplating, and I don't feel like coding a DLL for a one-off project.

The way I do this is by calling the LabVIEW internal memory manager function MoveBlock through a Call Library Node.

If you set the source parameter to be an uInt32 by value and the target parameter to be an uInt(x) by reference, and then also adjust the size parameter accordingly you get what is required.

To call MoveBlock in LabVIEW you have to configure the Call Library Node as follows:

Library Name: LabVIEW

Calling Convention: Standard C

Function Name: MoveBlock

return value: void

1. param: source, uInt32 as Value

2. param: target, uIntxx as Pointer

3. param: size, int32 (number of bytes to copy)

Advantage is that you do not need any Toolkits or plattform specific external libraries.

Rolf Kalbermatter

[Yuri33]

QUOTE(rolfk @ Jul 22 2007, 03:31 AM)

To call MoveBlock in LabVIEW you have to configure the Call Library Node as follows:

Library Name: LabVIEW

Calling Convention: Standard C

Function Name: MoveBlock

return value: void

1. param: source, uInt32 as Value

2. param: target, uIntxx as Pointer

3. param: size, int32 (number of bytes to copy)

Is there a list of undocumented calls like this to the LV library?

[Aristos Queue]

QUOTE(Yuri33 @ Jul 22 2007, 10:36 PM)

Is there a list of undocumented calls like this to the LV library?

No, and using such callbacks is a trick we go to great lengths to prevent folks from doing.

[i2dx]

QUOTE(Aristos Queue @ Jul 23 2007, 06:38 AM)

No, and using such callbacks is a trick we go to great lengths to prevent folks from doing.

That's a part of Murphys law: if there is a possibility to do such things, someone WILL do such things, whatever you do to prevent that

[LAVA 1.0 Content]

QUOTE(i2dx @ Jul 23 2007, 07:51 AM)

That's a part of Murphys law: if there is a possibility to do such things, someone WILL do such things, whatever you do to prevent that

"Listen to the expert they'll tell you what can't be done, then go do it !"

It was someone's signature on NI forum :thumbup:

[i2dx]

QUOTE(TiT @ Jul 23 2007, 09:06 AM)

"Listen to the expert they'll tell you what can't be done, then go do it !"

It was someone's signature on NI forum :thumbup:

It's Mike Ashes signature ... (e.g. http://forums.lavag.org/G-Math-or-other-expression-parser-in-LVRT-t7315.html&view=findpost&p=27663' target="_blank">in this post)

[Rolf Kalbermatter]

QUOTE(Yuri33 @ Jul 22 2007, 10:36 PM)

Is there a list of undocumented calls like this to the LV library?

It's not undocumented. It is all (except the Library:LabVIEW trick in the Call Library Node) there in the External Code Reference Manual.

Rolf Kalbermatter

QUOTE(Aristos Queue @ Jul 22 2007, 11:38 PM)

No, and using such callbacks is a trick we go to great lengths to prevent folks from doing.

Yea, I figured some of the password protected VIs might use this and similar tricks ;-)

But someone at NI must have forgotten that. There is or maybe used to be a code example on the Developer Exchange Site exactly with the MoveBlock function. So you hardly can call the Library:LabVIEW trick in the Call Library Node to be a well kept secret anymore.

Rolf Kalbermatter

[Aristos Queue]

QUOTE(rolfk @ Jul 23 2007, 05:18 PM)

But someone at NI must have forgotten that. There is or maybe used to be a code example on the Developer Exchange Site exactly with the MoveBlock function. So you hardly can call the Library:LabVIEW trick in the Call Library Node to be a well kept secret anymore.

True. Which is why licensing got applied to scripting. You probably don't want to promote the publicity of this lest similar protections come to the callback.

[crelf]

QUOTE(Aristos Queue @ Jul 24 2007, 08:29 AM)

True. Which is why licensing got applied to scripting.

We can do scripting in LabVIEW?!?

[Rolf Kalbermatter]

QUOTE(Aristos Queue @ Jul 23 2007, 05:29 PM)

True. Which is why licensing got applied to scripting. You probably don't want to promote the publicity of this lest similar protections come to the callback.

This sentiment! Is that official NI policy now? Maybe it has come the time to consider for me if LabVIEW is still the tool I love to work with.

Rolf Kalbermatter

[i2dx]

QUOTE(crelf @ Jul 24 2007, 01:30 AM)

We can do scripting in LabVIEW?!?

Of course you can. Noone can prevent you from creating a VI in LV 7.1.1 which contains all the scripting nodes you need. OK, maybe the code is less efficient and you will miss something, but it still works. I still use Scripting in my tools under LV 8.2.1, and I have developed new ones ... (and I found out many of the scripting nodes are now simply "private")

QUOTE(rolfk @ Jul 24 2007, 07:21 AM)

This sentiment! Is that official NI policy now? Maybe it has come the time to consider for me if LabVIEW is still the tool I love to work with.

that reminds me a little bit about Galileo Galilei ...

In a way I can understand AQs concerns, I interpret that as "don't make me more work as I allready have" (due to support, etc ...) on the other hand it is a fact, that humans are courious and have allways tried to gain more knowledge. This truth is expicid valid for IT gurus so it's wrong to blame the experts for trying to gain more knowledge. Last but not least that is what NI wants: a community of LV developers which has a broad base of knowledge!?

(I hope I am not wrong and the NI's favourite LV user likes the express functions most ... <shiver>)

[Aristos Queue]

QUOTE(rolfk @ Jul 24 2007, 12:21 AM)

This sentiment! Is that official NI policy now?

Nah, just my personal thought on the situation. I'm not privvy to the conversation that lead to the licensing of scripting. It just seems that no one around NI minds when the advanced customers dig stuff out of "LabVIEW's attic", but when it starts showing up among the general user base and creating a support burden, there starts to be grumbling about "never intended that to be opened up."

[crelf]

QUOTE(i2dx @ Jul 24 2007, 05:51 PM)

QUOTE(crelf)

We can do scripting in LabVIEW?!?

Of course you can.

I was kidding - hence the " "

[i2dx]

QUOTE(crelf @ Jul 25 2007, 01:39 AM)

Of course you can.

I was kidding - hence the " "

ah, ok, it's sometimes hard to notice a joke with my "bavarian english"

:beer:

[crelf]

QUOTE(i2dx @ Jul 25 2007, 03:44 PM)

ah, ok, it's sometimes hard to notice a joke with my "bavarian english"

No worries, sometimes my "Australian English" gets me in a lot of trouble