MatthewHarrison

Here is the output from the command:

Operating System:Build Number: 7600

Operating System:Detailed Name: Windows 7

Operating System:Name: Windows: x64

Operating System:Version Number: 6.1

Thank you for taking time to look at this.

Best Wishes,

Matt

Matthew out of curiosity (we would need to do some work on OpenG package builder as well)

could you run this code:

Ton

I wondered how much would be involved in the port. It sounds like there are several non-trivial aspects to it. Thank you for your willingness to look at this issue.

Best Wishes,

Matt

Well, there has recently been some work on the underlying ZLIB library to make it ready for 64 Bit. There is also a ZIP library on top of that that will require some careful review for 64 Bit compatibility. I think there might be a few issues there. Then there is also the VI library which would need to be updated to use pointer sized integers for some of the parameters. Last but not least this all needs to be compiled with a 64 Bit ready Windows compiler. I guess one of the Visual C Express Editions might do the trick but I haven't done any work in that direction yet.

I have plans to incorporate the recent ZLIB 1.2.5 version into it. This is mostly a simple replacement of existing files in the source code and should help to make that part fully 64 bit ready. Then I will need to setup a working 64 Bit compiler tool-chain somehow and get a bit familiar with it. The real work is trying to find areas where 64 Bit might cause issues. Even if the code compiles fine and seems to do work, that is no guarantee that all the critical areas are fine.

So all in all in it is quite some work and even more testing and I'm at the moment a little tied up with other stuff. I do intend to work on this if nobody else beats me to it, but it is for sure not just a recompile. And since the code changes in some ways there will be a new release of all shared libraries necessary and for true 64 bit support pre LabVIEW 8.0 support might have to vanish.

I'm porting some code to 64-bit LabVIEW 2009, and one thing that is not working is the OpenG Zip tools. It looks like the problem is that the .dll that the toolkit calls into is not executable in a 64-bit environment. This makes perfect sense, but I wonder if it would be possible to recompile lvzlib.dll to overcome this problem. Is the source code for this .dll available, or has this port already been done?

Best Wishes,

Matthew Harrison

Systems Engineer

Moore Good Ideas, Inc.

I so totally came up against this issue today - I have an app that can be built with different security modules in it (DSC, TestStand, Active Directory, etc), some of which require different run time licenses (eg: if a project is going to use the TestStand security module, I don't want the DSC code in the build, otherwise it'll get upset when it runs and doesn't find a DSC license). Having different build specs with conditional disable strucutres would fix this issue.

I've come across a similar issue, and I was wondering if you found a solution to the problem of programmatically setting the conditional disable symbols.

I'm not going to do the homework for you, but if you Google on: "Get BIOS Serial Number" and do a little research you can figure out a way to use the BIOS serial number on the unique machine. This is much less likely to be changed than a hard drive and is also more secure. I have seen cracking toolkits that explicitly give tools that get around hard drive security number methods.

Good luck.

I've been looking into this topic for while now, and without asking you to give too much away, is Windows Management Instrumentation (WMI) the right tree to be barking up?

-Matt

Well, I guess a related question would then be, "Is there any way to register for these shared variable value change events without the entire DSC module installed?" I don't mean to circumvent the need for the DSC which, I'm sure, is well worth it. It just seems that if that is all you want to do, there may be some other way.

-Matt

I'm not sure I understand what kind of pulse generation you really want, but perhaps the edited attachment will help you out. I don't think you were actually generating a pulse train the way you were doing it. You were just generating a single sample.

-Matthew Harrison

Download File:post-811-1144401277.vi