Foo - Win7/64bit question (and rant)
Bikeforums.net is a forum about nothing but bikes. Our community can help you find information about hard-to-find and localized information like bicycle tours, specialties like where in your area to have your recumbent bike serviced, or what are the best bicycle tires and seats for the activities you use your bike for.
03-30-10, 08:31 PM
I've used an MS Excel plugin (xla file w/dll) since the days of Win2k, and it's worked pretty well. It interfaces a data acquisition unit strait into excel, and I find it to be better suited to my needs than Labview, Matlab, etc. However, the new computer came with 64bit Windows 7 (last one was 32bit XP, Office2007). I tried the installer CD, no dice (error about 64bit versions of Windows). I tried it in compatibility mode, also no dice. I tried it on the built in XP virtual machine, that works, but isn't a good permanent solution. I then copied the installed folder (.xla file, couple .dll libraries) to the Win7 install. Load Excel, browse to add the plugin, and it works great. It talks to the box, samples data at 25kHz, does output, etc.
Now for the catch, if I close Excel, when I reload Excel I get an error "daswiz.dll" [my plugin] failed/could not load/something like that, and the plugin isn't there. If I disable the add-in, then re-enable it the problem does not go away. If I move the plugin file to a different directory, such that on load Excel prompts me to remove the add-in from the list, then I put it in again at the new location it works great...until I close Excel:mad:.
It seems like this should be a documented issue, but I can't seem to find it. If I don't come up with an answer in the pretty near future I'm just going to send the computer back and get one downgraded to XP. I'm trying to avoid that because I see future XP support as being a bit thin.
What is the plugin for?
By using 64bit Windows right now, unfortunately you are a bit of an early adapter. The lag in 64bit support has been slow and for once it's actually not really Microsoft's fault (though pushing Win 64 onto consumers who realistically don't benefit from it, may be M$'s fault).
Windows 7 is great, even in 32bit...
03-31-10, 03:58 AM
Depends upon which benefits you're looking for. Win7 is more optimized for 64-bit than previous versions and the biggest improvements are in running 64-bit programmes. Win7-64bit running 32-bit software is buggy and slow. Win7-32bit is actually slower than WinXP-32bit.
So it really comes down to what kind of applications you're using and what kind of tasks you wish to accomplish. For the OP's situation, I would just wipe out the Win7 and reload WinXP-32bit as that combination works so much better with his equipment and workflow patterns.
How often do you call Microsoft for support and pony up the $250 per call? Usually it's the hardware & software vendor that you go to with issues and most of the time, they know exactly what to do with your situation because you're not the only one using their product.
03-31-10, 06:15 AM
We tried the software vendor. Unfortunately they discontinued support on this product a while ago, and never made a replacement. They were happy to theorize, but didn't have anything useful. I did some more searching around and discovered that 64bit Win7 does not support 16bit applications, which this is. What I don't get is why I can get it to work once.
03-31-10, 10:38 AM
some types of older software, and software not labeled as Windows 7 compatible, can be loaded directly to C - do NOT use the suggested install path. You might even have to "manually" install instead of using the install sheild thing. Give that a try.
03-31-10, 03:06 PM
^^^Tried that, that's how we got it sort of running (albeit with many hoops to jump through each use). It claims the problem is a dll file with it not loading. As far as I can tell, the only thing in the DLL file is a dozen or so icons. Does anyone know of a good trial or freeware piece to opne a 16bit dll and resave it as 32 bit? I found one and tried it (resulted in the same error), but I still suspect I didn't get it right. Alternatively, can I e-mail one of you guys the dll for conversion? It's a pretty small file.
03-31-10, 11:30 PM
It's not that easy as the API calls from the application are very different between 16-bit vs. 32-bit applications. You need to re-write the program as well. One way to avoid the thunking is to convert the 16-bit DLL into a COM object. But again, you have to re-write the program to make COM calls.
You're basically re-creating the original developer's work for a different environment. Not as quick and easy as loading WinXP onto that machine.
04-01-10, 11:16 AM
I managed to get in to the VBA code and it is DLL calls causing the error. "loadlibrary" is returning null due to an error 48. Documentation on that implies that the dll is invalid given that the address is correct, which you have also said. Is there a simple way in VBA to call a COM rather than a DLL? With that, is there a simple way to convert a DLL to a COM without having the original DLL code? At this point we're just going to use the XP shell, it isn't as bad as I had previously thought. However, I would like to know how to make it work if only for my own future reference. Once upon a long time ago I knew VB, but that wasn't in this decade.
Powered by vBulletin® Version 4.1.12 Copyright © 2013 vBulletin Solutions, Inc. All rights reserved.