I am developing an application that works fine on many versions and variants of Windows, but fails on others, and I haven't been able to tell why, yet.
What information should I try to find out? The full version number and variant of their OS, for sure, and possibly environment variables. Is there a way to get information about patch levels (perhaps beyond which service packs are installed)? Should I try to get a list of active processes?
Is there an application or script they could run, and then send me a file to diff to try to figure out how their system differs from mine? (Barring that, does anyone has a list of instructions on how to obtain this information)?
[I have so far identified that my application runs fine on 32 bit versions of Windows -- tested on XP and 7 -- and works fine on Win 7 SP1 64-bit for me (Enterprise edition), but some of my users, using Win-7 64 bit (don't know the variation yet -- Home, Pro, Ultimate?) have trouble running a 32-bit JDK included with my program (which in turn accesses 32-bit drivers)].
Related
I recently had an issue where I was able to add an icon to a (VB6) form on one PC where it worked fine, but they was unable to run/compile it on a second PC.
It turned out that the icon file was 32-bit (including an alpha channel) and this was the problem. But I was surprised that this was a system-dependent feature.
(In this specific example it was Win10 x64 which allowed the 32-bit icon, and Win7 x32 which did not).
So now it seems quite unclear what icons are permissible to use in VB6 in which versions of Windows?
I have seen examples such as this question which have a similar issue, and this other question outlines what may have been the original VB6 features when it was new (?) but I can't yet find information that comprehensively breaks down what has changed based on Windows version.
This is important because we don't need to necessarily live within the limitations of (say) Windows XP if we know we are deploying to Windows 8 / 10 only. But nor do I want to risk that a fraction of users will have some dire problem because of this.
I've dug into this a little more - it appears that the Windows API function OleLoadPicturePath() behaves differently in the two Windows versions I mentioned above. On Win7, it will error out with a 32-bit icon; but on Win10 it does not. I'm not sure if there are other API functions which differ also, or not.
tl;dr: Device driver written in NuMega DriverStudio for Win95 to be upgraded to Win10 64-bit. What's the easiest path?
We have a very old product line, which is still selling well. One dll, accessing a UART in a way normal serial handlers can not (to support an even older protocol for another company's products), was made back when the product was first released - for Windows 98! Ever since, it has been working flawless (on 32-bit machines). Therefore, the code has never been touched since it's initial creation!! (This is based on the memory of a few of my colleagues who were around at the time). The only source I have been able to find is from 2001, although one file dates back to 1998.
The driver type is WDM
Now Microsoft have stopped providing 32-bit versions of Windows 10, and customers have started asking for a 64-bit version of our software, so I landed the task of figuring out how easiest to fix it - and support win7 through to Win10, 64-bit.
However the DriverStudio from NuMega was discontinued shortly after the company was purchased by Compuware (and they have lost all knowledge of it!), and even if we were able to find an old version (latest is from 2002), it's unlikely that it's going to help us very much.
I've been searching the web, but haven't found anything giving any suggestions to what the then users of DriverStudio did to upgrade their drivers.
At the time, Jungo WinDriver were an alternative that most people didn't consider to use for 'real' drivers, but perhaps times have changed?
Any advice on how to upgrade this driver code as easy as possible will be highly appreciated.
Installed Windows on my Galileo board and that works fine.
I developed a small application i Delphi7 (32 bit exe) that
I have deployed to the Galileo and configured it to start
at boot by configuration in the autorun.cmd file.
start C:\applications\GalileoApp1.exe
The application is formless and contains a TCPserver that echoes back incoming data.
Works fine under windows 7 on my PC.
Does not start automatically or manually on my Galileo.
Has anyone tried something similar and succeeded in executing the application on Galileo?
Are there any limitations on what types of 32bit exe´s that can be executed on the Galileo?
Stock Delphi RTL will not work on that version of Windows. The primary reason is that the Galileo versions of Windows' DLLs are different from the desktop version. This will require a rebuild of the RTL in order to import APis from their new locations. Some APis aren't even supported (such as most of the ones in GDI32 and USER32).
That being said, here at Embarcadero, as a research project I have a version of the Delphi RTL that does run on the Galileo board (I'm looking at the board right now :). I also have a stripped down Delphi conversion of some of the Wiring/Arduino Sketch API. When or even if we release such a thing is purely dependent upon the demand and our intended product direction.
The bottom line is that, yes, it is possible to get a Delphi-built command-line application (no visual VCL is supported, or anything that assumes the presence of a GUI). No, it's not a straight-forward, simple process as it requires some significant modifications to the RTL. I would also not recommend using Delphi 7, since the Galileo board doesn't support most of the Ansi versions of the Windows APIs. You will need a Unicode capable version of Delphi to start with.
I am trying to work out the least disruptive way of beginning to experiment with Windows 8 development. I currently have a Windows 7 Ultimate PC (plenty of disk space, RAM and i7 CPU), and I have a copy of Windows 8 (not 8.1).
I have considered various options:
Convert my whole machine to Windows 8. (Not ideal right now, as I am in the middle of other work, but I may have to do this eventually).
Dual boot Windows 7 & 8. (Can't get this to work. Windows 7 is already installed, and though I can get Windows 8 to install on the second HD, I can't get its boot menu to see Windows 7. I suspect this would be easier if I installed Windows 8 first, but that would be a huge pain.)
Run either OS using a virtual machine. (I haven't looked into this yet, and I have no idea what is involved.)
As a final option, I wondered if it is possible to develop Windows 8 applications on a Windows 7 PC and remote debug on an attached Windows 8 device? (I'd prefer to do this, as it is a way I have worked often in the past while doing console development.)
Does anyone have any experience of any of this - positive or negative? It takes ages to experiment with this stuff, with the constant threat of recking my existing work environment. I'd really appreciate any advice or pointers to articles that deal with any of this stuff.
Microsoft do their loyal developers no favours. I've paid hundreds for modern hardware, Windows versions and Visual Studio, and still it seems difficult to say the least to develop for their latest OS.
Kind wishes ~ Patrick
Option 4 is not possible. In similar situation I went with option 2 and gratually migrate myself completly to windows 8.
If you have problems with boot try to ask on superuser.com or better search the web for guideline.
If you want to develop applications for Windows 8 don't go with option 3.Please see this post on installing Visual studio in VM.
Regarding option 2,verbatim from Microsoft
You must install the older operating system first, and then install the more recent operating system. If you don't (for example, if you install Windows Vista on a computer already running Windows 7), you can render your system inoperable. This can happen because earlier versions of Windows don't recognize the startup files used in more recent versions of Windows and can overwrite them.
But as #Antonio said there may be roundabout for option 2.
I am trying to install Sheridan controls (ActiveThreed 2.01) on Win7 64-bit, but evidently it is a 16-bit installer so it won't execute.
What would be the best way to get round this problem?
Can anyone comment on whether http://homepage3.nifty.com/takeda-toshiya/msdos/index.html would be helpful?
It took me months of googling to find a solution for this issue. You don't need to install a virtual environment running a 32-bit version of Windows to run a program with a 16-bit installer on 64-bit Windows. If the program itself is 32-bit, and just the installer is 16-bit, here's your answer.
There are ways to modify a 16-bit installation program to make it 32-bit so it will install on 64-bit Windows 7. I found the solution on this site:
http://www.reactos.org/forum/viewtopic.php?f=22&t=10988
In my case, the installation program was InstallShield 5.X. The issue was that the setup.exe program used by InstallShield 5.X is 16-bit. First I extracted the installation program contents (changed the extension from .exe to .zip, opened it and extracted). I then replaced the original 16-bit setup.exe, located in the disk1 folder, with InstallShield's 32-bit version of setup.exe (download this file from the site referenced in the above link). Then I just ran the new 32-bit setup.exe in disk1 to start the installation and my program installed and runs perfectly on 64-bit Windows.
You can also repackage this modified installation, so it can be distributed as an installation program, using a free program like Inno Setup 5.
You can't run 16-bit applications (or components) on 64-bit versions of Windows. That emulation layer no longer exists. The 64-bit versions already have to provide a compatibility layer for 32-bit applications.
Support for 16-bit had to be dropped eventually, even in a culture where backwards-compatibility is of sacred import. The transition to 64-bit seemed like as good a time as any. It's hard to imagine anyone out there in the wild that is still using 16-bit applications and seeking to upgrade to 64-bit OSes.
What would be the best way to get round this problem?
If the component itself is 16-bit, then using a virtual machine running a 32-bit version of Windows is your only real choice. Oracle's VirtualBox is free, and a perennial favorite.
If only the installer is 16-bit (and it installs a 32-bit component), then you might be able to use a program like 7-Zip to extract the contents of the installer and install them manually. Let's just say this "solution" is high-risk and you should have few, if any, expectations.
It's high time to upgrade away from 16-bit stuff, like Turbo C++ and Sheridan controls. I've yet to come across anything that the Sheridan controls can do that the built-in controls can't do and haven't been able to do since Windows 95.
I posted some information on the Infragistics forums for designer widgets that may help you for this. You can view the post with the following link:
http://forums.infragistics.com/forums/p/52530/320151.aspx#320151
Note that the registry keys would be different for the different product and you may need to install on a 32 bit machine to see what keys you need.
I am mostly posting this in case someone comes along and is not aware
that VB2005 and VB2008 have update utilities that convert older
VB versions to it's format. Especially since no one bothered to
point that fact out.
Points taken, but maintenance of this VB6 product is unavoidable. It would also be costly in man-hours to replace the Sheridan controls with native ones. Simply developing on a 32-bit machine would be a better alternative than doing that. I would like to install everything on Win7 64-bit ideally. – CJ7
Have you tried utilizing the code upgrade functionality of VB Express 2005+?
If not,
1. Make a copy of your code - folder and all.
2. Import the project into VB express 2005.
This will activate the update wizard.
3. Debug and get the app running.
4. Create a new installer utilizing MS free tool.
5. You now have a 32 bit application with a 32 bit installer.
Until you do this, you will never know how difficult or hard it
will be to update and modernize the program.
It is quite possible that the wizard will update the Sheridan controls
to the VB 2005 controls. Again, you will not know if it does
and how well it does it until you try it.
Alternatively, stick with the 32 Bit versions of Windows 7 and 8.
I have Windows 7 x64 and a program that will not run. However,
the program will run in Windows 7 32 bit as well as Windows 8 RC 32 bit.
Under Windows 8 RC 32, I was prompted to enable 16 bit emulation
which I did and the program rand quite fine afterwords.
I had 32-bit software with a 16-bit installer that I couldn't unzip. I solved it with otvdm which allows you to run windows 1.x, 2.x, 3 programs on win64. In fact, otvdmw allows you to select the program to run (otvdm is command-line).
16 bit installer will not work on windows 7 it's no longer supported by win 7 the most recent supported version of windows that can run 16 bit installer is vista 32-bit even vista 64-bit doesn't support 16-bit installer....
reference http://support.microsoft.com/kb/946765
Bottom line at the top: Get newer programs or get an older computer.
The solution is simple. It sucks but it's simple. For old programs keep an old computer up and running. Some times you just can't find the same game experience in the new games as the old ones. Sometimes there are programs that have no new counterparts that do the same thing. You basically have 2 choices at that point. On the bright side. Old computers can run $20 -$100 and that can buy you the whole system; monitor, tower, keyboard, mouse and speakers. If you have the patience to run old programs you should have the patience to find what you are looking for in want ads. I have 4 old computers running; 2 windows 98, 2 windows xp. The my wife and I each have win7 computers.