If this is your first visit, be sure to check out the FAQ by clicking the link above. You may have to register before you can post: click the register link above to proceed. To start viewing messages, select the forum that you want to visit from the selection below. |
|
|
|
Thread Tools | Rate Thread | Display Modes |
#1
|
|||
|
|||
Win 10-64bit + VB6 + National PCI-GPIB card?
There's a lot of info on the web, but most of it predates
win10 by a decade. Even sites that claim win10 support seem to just prepend win10 to everything on the site to get your attention and let you download very old stuff. All the National Instruments software I can find claims to support only the newest GPIB hardware. I've tried V3.1.2, V16 and V17 without success. I have VB6 running a National PCI-GPIB card on windows 7 32-bit. This started out as XP and updated to win7. Attempts to install it on the same hardware with win10-64 (new install of 1709 pro with all updates) have failed. Attempts to install it on the same hardware with a new install of win 10-32 have failed. Attempts to install it on the same hardware with win 7-64 pro have failed. BUT, If I clone the working win7-32 disk and upgrade that to win 10-32, it all works fine. Visual Basic 6 works fine on all of the iterations. The driver for the GPIB card says it's working fine on all of the iterations. NiMAX finds the card and the readout of status is identical to the readout on the working win7-32 system. But, when VB calls the GPIB card, it complains that it's missing a file and I should install it. I've misplaced the scrap of paper containing the file name, but that file is nowhere to be found on the hard drive of the working system or via web search. I suspect that something got installed over the years by xp/7/10 that makes it work, but I have no idea how to figger out what that is. While I do have a working win10 system, it carries a lot of baggage. I'd also like to update it to 64-bit. I'm also interested in hearing if anybody has a GPIB system working on a Debian variant of linux. Software I can find supports only the red-hat variant. I have a lot of detail available, but if nobody has made 64-bit work, it won't help to post it. If anybody is interested in VB6, I found a website that shows how to convert the VS6 install disk to a more universal install/setup that puts VB6 on win10-32, win10-64 and linux mint 18.3cinnamon/wine with a few clicks. No need for a lot of fiddling to make it work. Yes, I'm aware that might be the root of my problem...maybe... I've got a few more options to try, but they're very time consuming. I just got a message from my router that I've downloaded 50GB of stuff this month trying to make all this work. |
Ads |
#2
|
|||
|
|||
Win 10-64bit + VB6 + National PCI-GPIB card?
"mike" wrote
| I have VB6 running a National PCI-GPIB card on windows 7 32-bit. | This started out as XP and updated to win7. | I don't know what "GPIB" is and I'm still running VS6 on XP, but I do know that later versions can trip up on outdated Java requirements: https://www.raymond.cc/blog/install-...hine-for-java/ The solution is apparently easy: Create a dummy Java library. If that's not the problem you might be better off asking in microsoft.public.vb.general.discussion. I'm sure some people there must be using Win10. |
#3
|
|||
|
|||
Win 10-64bit + VB6 + National PCI-GPIB card?
mike wrote:
There's a lot of info on the web, but most of it predates win10 by a decade. Even sites that claim win10 support seem to just prepend win10 to everything on the site to get your attention and let you download very old stuff. Download sites should be listing the system prerequisites according to the software maker's specifications. If a download site lies (you didn't mention where you went) then don't go there. Downloads should only be obtained from the software/hardware maker or from reputable download sites that scan their files for malware. All the National Instruments software I can find claims to support only the newest GPIB hardware. I've tried V3.1.2, V16 and V17 without success. The driver must know how to discover and communicate with the device. A driver for a different hardware device may not and likely will not work with a different hardware device unless it is a generic device (which the NI GPIB PCI card doesn't appear to be). At ni.com, I found: http://sine.ni.com/psp/app/doc/p/id/psp-1187 However, that doesn't mean that device name is for the PCI card that you have, especially since yours is quite old (and you never mentioned USB). If after contacting NI they say that the old hardware is not supported then you are likely stuck using that hardware with an old version of Windows supported by their old device driver and using a driver that supports that particular hardware. The device described at the above site page does NOT list Linux as a supported OS (other than Mac OS X). I don't know where you found information at the NI site claiming their device (or your old one) has (or had) support for use under other Linux distros. It took some digging into the ni.com site to find what might be your card by going to: http://www.ni.com/downloads/ni-drivers/ selecting "Entire site" in the search's dropdown list, searching on "gpib" (which fails to find anything but gives some hints), and clicking on the "PCI-GPIB" (non-plus version since you didn't mention having a plus version). That [eventually] led to: http://www.ni.com/en-us/shop/select/...modelId=122736 Alas, that had no links to drivers or even to a specifications page (perhaps because the device is unsupported). I went back to the search page, selected "Drivers", and searched on "PCI-GPIB" (again the non-plus version) which found: http://search.ni.com/nisearch/app/ma...rv/q/pci-gpib/ That search doesn't list driver(s) for the GPIB device (a lot of other non-GPIB devices are listed so their search sucks). Perhaps the "PCI-GPIB" device has a model number (e.g., NI-488) but you didn't mention a model number, so I cannot determine if the NI-488 drivers are for the "PCI-GPIB" device. You need to contact NI support on what driver to use with what hardware under what OS. Just because you've moved (or want to move) forward to a newer OS version doesn't mean they have, especially for ancient hardware. NI has their own peer support forums at: https://forums.ni.com/ni/board/crawl...ssage.id=60119 where you might find a community more focused on that particular hardware. I didn't bother reviewing their forums to determine if they are reasonably active so you could get other users to help you. I have VB6 running a National PCI-GPIB card on windows 7 32-bit. This started out as XP and updated to win7. VB6 = Visual Basic 6. That is a programming language, not a hardware driver. The interface for the hardware must be defined in an OS so the OS knows how to communicate with that hardware. Attempts to install it on the same hardware with win10-64 (new install of 1709 pro with all updates) have failed. Attempts to install it on the same hardware with a new install of win 10-32 have failed. Attempts to install it on the same hardware with win 7-64 pro have failed. BUT, If I clone the working win7-32 disk and upgrade that to win 10-32, it all works fine. Visual Basic 6 works fine on all of the iterations. The driver for the GPIB card says it's working fine on all of the iterations. NiMAX finds the card and the readout of status is identical to the readout on the working win7-32 system. But, when VB calls the GPIB card, it complains that it's missing a file and I should install it. I've misplaced the scrap of paper containing the file name, but that file is nowhere to be found on the hard drive of the working system or via web search. I suspect that something got installed over the years by xp/7/10 that makes it work, but I have no idea how to figger out what that is. Sometimes the embedded drivers (or interface definitions for generic hardware types) included in a version of Windows is sufficient to communicate with old hardware; however, not all features may be available in the generic drivers. Old drivers are not moved ad infinitum to newer versions of the OS since device support may no longer be available or possible. While I do have a working win10 system, it carries a lot of baggage. I'd also like to update it to 64-bit. You cannot update from a 32-bit version of Windows to a 64-bit version. YOu have to install a new instance of 64-bit Windows. You can upgrade from one version to another of Windows while remaining at the same bitwidth. I'm also interested in hearing if anybody has a GPIB system working on a Debian variant of linux. Software I can find supports only the red-hat variant. Red Hat is payware because it is a Linux distro based on free CentOS but also includes proprietary code along with support. Red Hat is a customized Linux distro. While you can obtain a copy of the enterprise edition of Red Hat for free at: https://developers.redhat.com/blog/2...now-available/ that is overkill for your needs. Get CentOS (https://www.centos.org/), a community rebuild of Red Hat). If you want more bleeding/leading edge features in that distro then get Fedora (https://getfedora.org/). There are *NIX newsgroups to inquire about that OS. *NIX is off-topic here. I have a lot of detail available, but if nobody has made 64-bit work, it won't help to post it. Bitwidth of drivers *MUST* match the bitwidth of the operating system. For 64-bit Windows, you need 64-bit drivers for the hardware. If the hardware is abandoned for whatever reason the hardware vendor does not provide 64-bit drivers for old hardware then you are stuck with either using an old version of the operating system or with a lesser bitwidth of the hardware driver. If a hardware maker doesn't list OS support for their hardware, it is at your risk hoping an old driver (same bitwidth as the OS) will work in a later version of the OS. If the hardware is critical and has no support beyond an old version of the OS then you do NOT move to a later version of the OS. I still have an old Windows 98 machine because of a legal-sized scanner that has no driver and instead the scanner maker embedded the hardware interface definition within their software. The OS (and other apps) cannot communicate with that hardware. Only the scanner's software knows how to interface with that hardware. They didn't provide a later version of the scanner software to work on later versions of Windows. No generic drivers would recognize that scanner. My choices were to get a newer legal scanner with newer software and/or driver that would support a later version of Windows or stick with the old version of Windows along with the old and unsupported version of scanner software. I rarely use that scanner so the cheaper solution was to leave a Win98 box on a basement desk with the old legal scanner attached to it and continue using the old unsupported software. It wasn't like I wanted to use that old PC with its ancient hardware for anything else, anyway. Stay with an old version of Windows under which the old and unsupported hardware still works with an old driver. You have not yet qualified why you need to move to a newer version of Windows. You did not report that the old hardware with the old driver under the old OS was not working. |
#4
|
|||
|
|||
Win 10-64bit + VB6 + National PCI-GPIB card?
On 1/31/2018 5:35 AM, Mayayana wrote:
"mike" wrote | I have VB6 running a National PCI-GPIB card on windows 7 32-bit. | This started out as XP and updated to win7. | I don't know what "GPIB" is and I'm still running VS6 on XP, but I do know that later versions can trip up on outdated Java requirements: https://www.raymond.cc/blog/install-...hine-for-java/ The solution is apparently easy: Create a dummy Java library. If that's not the problem you might be better off asking in microsoft.public.vb.general.discussion. I'm sure some people there must be using Win10. I don't think this is a VB6 problem. It think it has to do with changes in the way win10 links VB6 to the NI-4882 GPIB card drivers. Since it works on a 23-bit win10 migrated from win7, you should be able to make it work on a 32-bit win10 fresh install. I may never get it to run on 64-bit anything...but that's the goal. There are lotsa sites with this kind of stuff. If you do this: http://www.planetsourcecode.com/vb/s...74428&lngWId=1 you end up with a single 33MB file that you click to install. 2 years from now, when you need to install it, you won't have to go searching for why it doesn't work, because it just does. Seems to work on win7, win10, linux mint cinnamon/wine. I like simple stuff that you don't have to remember. |
#5
|
|||
|
|||
Win 10-64bit + VB6 + National PCI-GPIB card?
On 1/31/2018 8:11 AM, VanguardLH wrote:
mike wrote: There's a lot of info on the web, but most of it predates win10 by a decade. Even sites that claim win10 support seem to just prepend win10 to everything on the site to get your attention and let you download very old stuff. Download sites should be listing the system prerequisites according to the software maker's specifications. If a download site lies (you didn't mention where you went) then don't go there. Downloads should only be obtained from the software/hardware maker or from reputable download sites that scan their files for malware. All the National Instruments software I can find claims to support only the newest GPIB hardware. I've tried V3.1.2, V16 and V17 without success. The driver must know how to discover and communicate with the device. A driver for a different hardware device may not and likely will not work with a different hardware device unless it is a generic device (which the NI GPIB PCI card doesn't appear to be). At ni.com, I found: http://sine.ni.com/psp/app/doc/p/id/psp-1187 However, that doesn't mean that device name is for the PCI card that you have, especially since yours is quite old (and you never mentioned USB). If after contacting NI they say that the old hardware is not supported then you are likely stuck using that hardware with an old version of Windows supported by their old device driver and using a driver that supports that particular hardware. The device described at the above site page does NOT list Linux as a supported OS (other than Mac OS X). I don't know where you found information at the NI site claiming their device (or your old one) has (or had) support for use under other Linux distros. It took some digging into the ni.com site to find what might be your card by going to: http://www.ni.com/downloads/ni-drivers/ selecting "Entire site" in the search's dropdown list, searching on "gpib" (which fails to find anything but gives some hints), and clicking on the "PCI-GPIB" (non-plus version since you didn't mention having a plus version). That [eventually] led to: http://www.ni.com/en-us/shop/select/...modelId=122736 Alas, that had no links to drivers or even to a specifications page (perhaps because the device is unsupported). I went back to the search page, selected "Drivers", and searched on "PCI-GPIB" (again the non-plus version) which found: http://search.ni.com/nisearch/app/ma...rv/q/pci-gpib/ That search doesn't list driver(s) for the GPIB device (a lot of other non-GPIB devices are listed so their search sucks). Perhaps the "PCI-GPIB" device has a model number (e.g., NI-488) but you didn't mention a model number, so I cannot determine if the NI-488 drivers are for the "PCI-GPIB" device. You need to contact NI support on what driver to use with what hardware under what OS. Just because you've moved (or want to move) forward to a newer OS version doesn't mean they have, especially for ancient hardware. NI has their own peer support forums at: https://forums.ni.com/ni/board/crawl...ssage.id=60119 where you might find a community more focused on that particular hardware. I didn't bother reviewing their forums to determine if they are reasonably active so you could get other users to help you. I've been all over that site and the forums. Since the problem seems to be confined to win10, here is as good a place as any to proceed. I have VB6 running a National PCI-GPIB card on windows 7 32-bit. This started out as XP and updated to win7. VB6 = Visual Basic 6. That is a programming language, not a hardware driver. The interface for the hardware must be defined in an OS so the OS knows how to communicate with that hardware. Yes, that's what the NI-488 software/driver is for. It all works on a win10-32 system migrated from win7. That suggests that it might be made to work on a newly installed fresh win10. That's what I seek. I started the quest on win10-64, but that may be a lost cause. The interesting thing is that, on a win10-64 system, the NiMAX configuration software v16 or v17 has no problem finding and configuring the GPIB card. VB6-SP6 seems to work until it needs to access the GPIB card. Evidence suggests that the problem is the linkage between VB6-SP6 and the driver. More experiments are in order. Attempts to install it on the same hardware with win10-64 (new install of 1709 pro with all updates) have failed. Attempts to install it on the same hardware with a new install of win 10-32 have failed. Attempts to install it on the same hardware with win 7-64 pro have failed. BUT, If I clone the working win7-32 disk and upgrade that to win 10-32, it all works fine. Visual Basic 6 works fine on all of the iterations. The driver for the GPIB card says it's working fine on all of the iterations. NiMAX finds the card and the readout of status is identical to the readout on the working win7-32 system. But, when VB calls the GPIB card, it complains that it's missing a file and I should install it. I've misplaced the scrap of paper containing the file name, but that file is nowhere to be found on the hard drive of the working system or via web search. I suspect that something got installed over the years by xp/7/10 that makes it work, but I have no idea how to figger out what that is. Sometimes the embedded drivers (or interface definitions for generic hardware types) included in a version of Windows is sufficient to communicate with old hardware; however, not all features may be available in the generic drivers. Old drivers are not moved ad infinitum to newer versions of the OS since device support may no longer be available or possible. While I do have a working win10 system, it carries a lot of baggage. I'd also like to update it to 64-bit. You cannot update from a 32-bit version of Windows to a 64-bit version. I'm gonna try to make GPIB work on a win7-64 system and upgrade that to win10 and see if that works. YOu have to install a new instance of 64-bit Windows. You can upgrade from one version to another of Windows while remaining at the same bitwidth. I'm also interested in hearing if anybody has a GPIB system working on a Debian variant of linux. Software I can find supports only the red-hat variant. Red Hat is payware because it is a Linux distro based on free CentOS but also includes proprietary code along with support. Red Hat is a customized Linux distro. While you can obtain a copy of the enterprise edition of Red Hat for free at: https://developers.redhat.com/blog/2...now-available/ that is overkill for your needs. Get CentOS (https://www.centos.org/), a community rebuild of Red Hat). If you want more bleeding/leading edge features in that distro then get Fedora (https://getfedora.org/). There are *NIX newsgroups to inquire about that OS. *NIX is off-topic here. I'm not interested in any of those versions. Too restricted in what you can do easily and I don't wanna become a guru. I want something mainstream for ordinary desktop users like Mint that's easier to configure and use. I have a lot of detail available, but if nobody has made 64-bit work, it won't help to post it. Bitwidth of drivers *MUST* match the bitwidth of the operating system. For 64-bit Windows, you need 64-bit drivers for the hardware. I expect that's the case at the raw hardware level, but sometimes the gurus find ways of porting old stuff. That's what I seek. If the hardware is abandoned for whatever reason the hardware vendor does not provide 64-bit drivers for old hardware then you are stuck with either using an old version of the operating system or with a lesser bitwidth of the hardware driver. If a hardware maker doesn't list OS support for their hardware, it is at your risk hoping an old driver (same bitwidth as the OS) will work in a later version of the OS. Yes, that's the plan. If I gave up on every piece of old hardware, I'd have to take a boatload of stuff to recycle. If the hardware is critical and has no support beyond an old version of the OS then you do NOT move to a later version of the OS. Sounds like you don't do much searching for hardware drivers for old stuff. Most of the driver download sites now want to install their installer that lets you install the drivers on their site...no thanks. Those that don't do that typically show search results that claim their driver supports win10/8/7/vista/xp, but when you download it, you find that it's the 20 year old win95 driver that you already have that doesn't work. This is not about finding vendor supported drivers. It's about finding people who have figgered out how to make the old drivers work in the new machine/OS. Stay with an old version of Windows under which the old and unsupported hardware still works with an old driver. You have not yet qualified why you need to move to a newer version of Windows. You did not report that the old hardware with the old driver under the old OS was not working. I seek to transcend that and get as much stuff as possible working in win10 AND a Debian derivative linux. I'd like to convert everything to linux and cut MS free, but I'm not confident that can ever happen. |
#6
|
|||
|
|||
Win 10-64bit + VB6 + National PCI-GPIB card?
"mike" wrote
| There are lotsa sites with this kind of stuff. | If you do this: | http://www.planetsourcecode.com/vb/s...74428&lngWId=1 | | you end up with a single 33MB file that you click to install. | 2 years from now, when you need to install it, you won't have | to go searching for why it doesn't work, because it just does. | Seems to work on win7, win10, linux mint cinnamon/wine. | That's an interesting one. Does there happen to be a similar thing for VS6? I'm not sure I'd ever need it, but it would be nice to know. you're running VB under WINE? Sounds like quite an adventure. |
#7
|
|||
|
|||
Win 10-64bit + VB6 + National PCI-GPIB card?
On 1/31/2018 3:23 PM, Mayayana wrote:
"mike" wrote | There are lotsa sites with this kind of stuff. | If you do this: | http://www.planetsourcecode.com/vb/s...74428&lngWId=1 | | you end up with a single 33MB file that you click to install. | 2 years from now, when you need to install it, you won't have | to go searching for why it doesn't work, because it just does. | Seems to work on win7, win10, linux mint cinnamon/wine. | That's an interesting one. Does there happen to be a similar thing for VS6? I'm not sure I'd ever need it, but it would be nice to know. Haven't looked for one. I'm allergic to "C". you're running VB under WINE? Sounds like quite an adventure. The long-term objective is to convert my lab system to desktop linux (Debian variant) without learning C. Recent versions of desktop linux are tantalizingly close to usable by a mere windows refugee. Dual booting doesn't work if you need two things that are not functional on both operating systems. Virtual machines have trouble with non-generic hardware interfaces. I've had a lot of issues with some upgrade to virtualbox deactivating a windows installation in VB. GPIB instrument control has been a roadblock, but there was a new release of linux gpib support recently. GAMBAS is close enough to VB6, but had a lot of "not implemented" functionality last time I looked. Despite the disappointing results at Winehq.org, Wine seems to be able to run VB6-SP6 at the top level. Will save some porting if I can just use VB6. Remains to be seen what will happen when I try to figger out how to get it to access the GPIB card. The whole thing with win10 and GPIB is a diversion because I have it working on win10 upgraded from win7, but can't fresh-install/reproduce a working win10 system. Probably a simple solution that's obvious the SECOND time you do it. |
#8
|
|||
|
|||
Win 10-64bit + VB6 + National PCI-GPIB card?
On 01/02/2018 01:31, mike wrote:
The long-term objective is to convert my lab system to desktop linux (Debian variant) without learning C. Recent versions of desktop linux are tantalizingly close to usable by a mere windows refugee. Then go and do it and stop crying here like a small baby. Windows 10 is for intelligent people; not for whimps like you. First you don't even have the brain to visit their forum and ask them why their software or drivers is not compliant with Windows 10. You are not likely to get anybody using archaic software or driver on "State of the Art" operating system like Windows 10. We don't cry like you because we use common sense which, unfortunately, is not common with you. The whole thing with win10 and GPIB is a diversion because I have it working on win10 upgraded from win7, but can't fresh-install/reproduce a working win10 system. Probably a simple solution that's obvious the SECOND time you do it. Exactly, you are so stupid that you can't even read what the EXACT error message is. If some file is missing then you need to download that file. I suspect you don't have the correct run-time library for Microsoft Visual C++ Redistributable for Visual Studio 2012 Update 4 or some later versions (or even prior versions). However, because you won't understand the technicalities involved, I won't bother to advice you further on this here. -- With over 600 million devices now running Windows 10, customer satisfaction is higher than any previous version of windows. |
#9
|
|||
|
|||
Win 10-64bit + VB6 + National PCI-GPIB card?
"mike" wrote
| The long-term objective is to convert my lab system | to desktop linux (Debian variant) without learning C. | Recent versions of desktop linux are tantalizingly close | to usable by a mere windows refugee. | | Dual booting doesn't work if you need two things that | are not functional on both operating systems. | Virtual machines have trouble with non-generic hardware interfaces. | I've had a lot of issues with some upgrade to virtualbox | deactivating a windows installation in VB. | I can sympathize with that plan. I've used dual booting in the past, but mostly just for experimenting. I don't see the point of VMs. Something's not right if one needs to run an OS in an OS. (As with the Mac people who rave about Mac superiority but, well, yeah, of course, the also boot Windows in a VM when they need to use software. I seriously tried Linux a few times, tried cooperating with the WINE people, and tried Gambas. At some point I felt like all of it was a waste of time. I could survive on Linux, but it's not fun like Windows. The Gambas author seemed to have an axe to grind, being obsessed with teaching VBers how wrong their code is. The whole thing felt condescending to me. WINE seemed promising at first, but I gradually came to sense that it was really just a lot of Linux geeks, stuck in adolescence, who want to use Windows games. They have no interest in finishing the thing and even less interest in providing an actual API for Windows programmers to use. If they documented their version of the API then we could write to WINE, rather than just hoping things would run under WINE. But they've made somewhat of a mess of it, sprinkling API support in a willy nilly manner across libraries. A kernel function might be in the WINE kernel library, or it might be in another. It's almost as thought they try to obfuscate it, but I suspect it's probably just lack of planning: Someone wants to be able to play the latest Grand Theft Auto and needs to support new APIs to do it, so they throw those in somewhere and they're happy until next time, when they want to be able to shoot aliens with a grenade launcher and can't do it. It's all a bit like standing on the last stone halfway across a stream. My heart's not into stepping on to any of the options available: Windows becoming restricted spyware, Mac being an exploitive, overpriced toy, or Linux, a perennially half-finished project that will probably never be polished enough to not require running incantations in console Windows. But if I ever have to leave Windows I guess Linux will be the only realistic option. I can't see using Win10. It's too far gone down a dark road. But there's always hoping that MS will eventually see a business case for going back to a solid, controllable OS as one of their products. There's certainly a business case for making a pliable Windows version that corporate customers can write custom, in-house software on. |
#10
|
|||
|
|||
Win 10-64bit + VB6 + National PCI-GPIB card?
On 1/31/2018 8:41 PM, Mayayana wrote:
"mike" wrote | The long-term objective is to convert my lab system | to desktop linux (Debian variant) without learning C. | Recent versions of desktop linux are tantalizingly close | to usable by a mere windows refugee. | | Dual booting doesn't work if you need two things that | are not functional on both operating systems. | Virtual machines have trouble with non-generic hardware interfaces. | I've had a lot of issues with some upgrade to virtualbox | deactivating a windows installation in VB. | I can sympathize with that plan. I've used dual booting in the past, but mostly just for experimenting. I don't see the point of VMs. Something's not right if one needs to run an OS in an OS. (As with the Mac people who rave about Mac superiority but, well, yeah, of course, the also boot Windows in a VM when they need to use software. I seriously tried Linux a few times, tried cooperating with the WINE people, and tried Gambas. At some point I felt like all of it was a waste of time. I could survive on Linux, but it's not fun like Windows. Your experience mirrors mine. I keep at it because it's a hobby. And "waste of time" is the very definition of a hobby. Remember how the do-gooders advocated giving the less fortunate in the world a lifestyle equal to theirs? Little did they realize that it would be done by REDUCING their standard of level to that of the less fortunate. Same thing is happening in desktop computing. Windows is increasingly invasive and annoying. May not be long before desktop linux and windows are "equivalent". The Gambas author seemed to have an axe to grind, being obsessed with teaching VBers how wrong their code is. The whole thing felt condescending to me. I played with XBasic back in the day because it was cross-platform. VB6 blew it away, and I never looked back. Gambas also looked promising. Back when I tried it, there were many instances of "this is not implemented yet". I'm expecting it to get more inclusive over time, but I haven't taken a deep dive in it. WINE seemed promising at first, but I gradually came to sense that it was really just a lot of Linux geeks, stuck in adolescence, who want to use Windows games. They have no interest in finishing the thing and even less interest in providing an actual API for Windows programmers to use. That's the root cause of the desktop linux chaos...individuals working in relative isolation to meet their personal needs. Organization is not in their vocabulary. Chaos is actively pursued. If they documented their version of the API then we could write to WINE, rather than just hoping things would run under WINE. But they've made somewhat of a mess of it, sprinkling API support in a willy nilly manner across libraries. A kernel function might be in the WINE kernel library, or it might be in another. It's almost as thought they try to obfuscate it, but I suspect it's probably just lack of planning: Someone wants to be able to play the latest Grand Theft Auto and needs to support new APIs to do it, so they throw those in somewhere and they're happy until next time, when they want to be able to shoot aliens with a grenade launcher and can't do it. I don't really care what's under the hood as long as it just works. But you have, perhaps, defined the root of the problem. It's all a bit like standing on the last stone halfway across a stream. My heart's not into stepping on to any of the options available: Windows becoming restricted spyware, Mac being an exploitive, overpriced toy, or Linux, a perennially half-finished project that will probably never be polished enough to not require running incantations in console Windows. Eventually, Microsoft will succeed in forcing developers to drop support for win7. All they have to do is make it less costly to use newer incompatible tools than to support older OS's. We will eventually be forced to change to win10 to continue posting our cat pictures. ;-) I got the win7 ultimate DVD when I attended the launch event. Still took me over 4 years to decide that changing to win7 was simpler than not changing to win7. Same thing is happening with win10. I got the free digital license for everything that would take it, but still have no win10 systems in daily use. But I'm prepared and learning about it every day. I'll be ready when the time comes. And it makes a great hobby. But if I ever have to leave Windows I guess Linux will be the only realistic option. Desktop linux is unlikely to become a viable option. It's gonna require a major reduction in expectations and losing compatibility with the rest of the world. Joe Average has shown that he's willing to use Android if it lets him tweet. The herd doesn't want what you and I want. They're gonna use whatever comes on their shiny new computer. I can't see using Win10. It's too far gone down a dark road. But there's always hoping that MS will eventually see a business case for going back to a solid, controllable OS as one of their products. Not gonna happen. They see how much money google is making and want a piece of that. They're never going back. We have to make the best of what they offer. Having said that, I use linux tools, ported to windows, and freeware for everything feasible. I use as little of the built-in MS stuff as is feasible. That provides considerable freedom from the whims of MS. There's certainly a business case for making a pliable Windows version that corporate customers can write custom, in-house software on. This afternoon, I had occasion to talk with a recent Tektronix retiree. She talked about how they'd have 8-hour test suites running and win10 would just disrupt the test to do updates. There wasn't much they could do about it. Before I met windows 10, my internet data consumption was about 3GB/month. This month, I've used over 50GB, and almost all of that is win10 related...and I'm not even using it as a primary OS. |
#11
|
|||
|
|||
Win 10-64bit + VB6 + National PCI-GPIB card?
On 1/31/2018 6:55 PM, Good Guy wrote:
However, because you won't understand the technicalities involved, I won't bother to advice you further on this here. Please have the tenacity to stick with that policy. Put me in your kill file and the world will be a better place. |
#12
|
|||
|
|||
Win 10-64bit + VB6 + National PCI-GPIB card?
On Wed, 31 Jan 2018 14:55:10 -0800, mike wrote:
If I gave up on every piece of old hardware, I'd have to take a boatload of stuff to recycle. That's why I take a small load of old hardware to the donation center 3-4 times a year. I don't want it to accumulate to the point where it becomes a boatload. |
#13
|
|||
|
|||
Win 10-64bit + VB6 + National PCI-GPIB card?
Still no explicit reason given as to why you need to move away from a
working setup using an older version of Windows to a non-working, flaky, or unknown (from unknown sources) setup with a new version of Windows. What does Windows 10 give you that is critical to your application? Is the OS more important than what appears to be critical hardware for whatever is your application of that hardware? Which is more critical: the hardware, the software, or the OS? So far, the only inferred reason you think you need to "transcend" to a newer OS is simply because a new one exists (exemplified by consumers well-trained by the "newer is better" marketing mantra). Because of the time you've already spent trying to migrate the old hardware into the newest Windows, it seems the old hardware is important to you and perhaps critical to some application involving that old hardware. Since that hardware is old, I suspect so is the computer with which that hardware is used. You really want to move forward to a new OS lugging along the old computer? Get a new computer for the new OS and keep using the critical old hardware with the old computer. Yeah, that means spending money but so would buying new hardware just to get it compatible with a new OS. To me, the OS is just the "player" of the software or hardware that I want to use. I pick the hardware and software FIRST. The OS is the plate on which the hardware and software are served. The OS is not the destination, just the road to get you there. The right tool for the job. Doesn't look like Windows 10 is the right tool unless you buy new and supported hardware along with the software/driver for that new hardware that works under Windows 10. Moving forward to a new OS with the old hardware had you take the wrong road where you hit a wall. Compatibility for hardware and software is part of the planning when migrating to a new OS, even to a new version of it and especially if switching to a different OS. Decide which is most important or critical: the latest Windows or the old hardware. Doesn't look like you'll get both and at no additional cost. You could buy new hardware that works under the new OS but that will cost money. You could pay a programmer to write a new driver for the old hardware that works under the new OS but that will cost money. You could switch to Linux and hope a new driver for the old hardware works under that different OS but the cost is your learning curve for the new OS along with later troubleshooting to get it all to work. Or you could stick with the old OS and the old hardware which has you spending no additional money nor any additional learning time. |
#14
|
|||
|
|||
Win 10-64bit + VB6 + National PCI-GPIB card?
On 2/1/2018 1:39 PM, VanguardLH wrote:
Still no explicit reason given as to why you need to move away from a working setup using an older version of Windows to a non-working, flaky, or unknown (from unknown sources) setup with a new version of Windows. What does Windows 10 give you that is critical to your application? Is the OS more important than what appears to be critical hardware for whatever is your application of that hardware? Which is more critical: the hardware, the software, or the OS? So far, the only inferred reason you think you need to "transcend" to a newer OS is simply because a new one exists (exemplified by consumers well-trained by the "newer is better" marketing mantra). Lighten up!! It's a hobby. Making win10 and Linux yield to my needs is something to do. It's progress. If you think you'll never have need for win10, you won't be doing much in the future. More and more applications are dropping support for 32bit operating systems. Don't need it today, but you will tomorrow. My motives are mine. They don't have to agree with yours. Helping me is your choice...do or don't. Latest National GPIB drivers seem to be working just fine using the national direct access tools. The VB6 problems seem to revolve around 32:64bit issues. DLLs seem to get randomly distributed around system32, syswow64 and system directories. It doesn't match up, so the app can't find what it needs. Still working on that. I gave up on the new VB6 install thru inosetup. Simple programs work, but the package distribution tools don't. Full VS6 install is better, but still no cigar...yet. One thing I still can't get my head around is that I can make an install file on a fully functional 32-bit win7 system, and it still won't install properly on win10-64. It gets stuffed into program files(x86), so it knows it's a 32-bit program. The files it can't find are right there in the directory. I even repackaged the app to put all the system support files into the app directory. Still no go. I'm able to get very simple GUI VB6 programs to run in linux/wine, but hardware access is an issue. There's a recent update to linux-gpib so all is not lost yet. |
#15
|
|||
|
|||
Win 10-64bit + VB6 + National PCI-GPIB card?
mike wrote:
On 2/1/2018 1:39 PM, VanguardLH wrote: Still no explicit reason given as to why you need to move away from a working setup using an older version of Windows to a non-working, flaky, or unknown (from unknown sources) setup with a new version of Windows. What does Windows 10 give you that is critical to your application? Is the OS more important than what appears to be critical hardware for whatever is your application of that hardware? Which is more critical: the hardware, the software, or the OS? So far, the only inferred reason you think you need to "transcend" to a newer OS is simply because a new one exists (exemplified by consumers well-trained by the "newer is better" marketing mantra). Lighten up!! It's a hobby. Making win10 and Linux yield to my needs is something to do. It's progress. If you think you'll never have need for win10, you won't be doing much in the future. More and more applications are dropping support for 32bit operating systems. Don't need it today, but you will tomorrow. My motives are mine. They don't have to agree with yours. Helping me is your choice...do or don't. Latest National GPIB drivers seem to be working just fine using the national direct access tools. The VB6 problems seem to revolve around 32:64bit issues. DLLs seem to get randomly distributed around system32, syswow64 and system directories. It doesn't match up, so the app can't find what it needs. Still working on that. I gave up on the new VB6 install thru inosetup. Simple programs work, but the package distribution tools don't. Full VS6 install is better, but still no cigar...yet. One thing I still can't get my head around is that I can make an install file on a fully functional 32-bit win7 system, and it still won't install properly on win10-64. It gets stuffed into program files(x86), so it knows it's a 32-bit program. The files it can't find are right there in the directory. I even repackaged the app to put all the system support files into the app directory. Still no go. I'm able to get very simple GUI VB6 programs to run in linux/wine, but hardware access is an issue. There's a recent update to linux-gpib so all is not lost yet. Do they need to be registered ? https://en.wikipedia.org/wiki/Regsvr32 I haven't a clue as to when something should be registered and when it will be resolved via $PATH or something. My little programs here have never been complicated enough to need it. Paul |
|
Thread Tools | |
Display Modes | Rate This Thread |
|
|