We have a legacy vb6 program using Active Reports 2. We have been running on a mix of OS's from xp sp2 to Win7 64bit. We have everything working except on one specific machine. This machine (win7 64bit), when displaying certain active reports report, the back ground image is not stretching to fill the page like expected. I've check all of the in house software installation and dll versions to see if something was not installed, but I cannot find anything different. I'm starting to think it must be a low level dependency of Active Reports 2 but I cannot find that either.
Does anyone have any ideas I can try to further trouble shoot the issue?
Custom DPI? In win7 it's much simpler to change to custom DPI besides "small fonts" and "large fonts" previous version used to have.
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.
I have had basic tests for meteor on a Windows7 PC.
But there the application crashed too often.
Before this, I tested meteor on PC running Windows8. There, crashes happened much less often and generally they were recovered when I shutdown and rebooted the meteor.
Is Meteor unstable on windows7?
Or is there any way to avoid this?
The version packaged to the MSI installer that can be found on win.meteor.com is not official. If you want a more stable, try the virtualized option I've described on the site. I've been using that for a month without issues.
Please could you be specific about what problems you are seeing, for example, what do you mean by 'crash'.
You can certainly raise issues on SO, but if they appear to be specific to the windows port, please raise a ticket at: https://github.com/sdarnell/meteor
The only difference between Win7 and Win8 meteor, is that the installer sets the Win7 compatibility mode for the node.exe executable on Windows 8.
There are also relatively few differences between the windows port of meteor and the official linux/mac release. So there is a possibility that the issue is either environmental (e.g. you have different things installed on the two machines), or it may even be a core issue that just happens to appear more often Win7 due to timing issues (there was a case of this in 0.6.3).
I'am learning some Gamedevelopment using Monogame.
I started a Windows OpenGL Project and everything works fine on my Win8 machine.
I have compiled the project and sent it to 2 People, both are using win7 x64 and one of them can't open the Game.
After that, I tested it on my other computer (also win7 x64) and I get the same problem, the game process starts, then the screen flashes (Aero seems to deactivate), then everything gets back to normal and the process of my game crashes without a message.
I'm sure, that there is no problem with my code, maybe some missing dlls but most of them are copied with the game
Lidgren.Network.dll
MonoGame.Framework.dll
OpenTK.dll
SDL.dll
Tao.Sdl.dll
Sincerely
CarnVanBeck
If it's taking down Windows Aero, it might be a graphics issue. Compare the graphical capability of the Win7 machine that can run it with the one(s) that can't. Does the working one have a graphics card? I seem to remember Monogame having odd behaviour with the Reach graphics profile.
Ok I fixed it using an OpenAL32 installer
I found the solution here
You have to install it, if your game doesn't work.
fixed it for me on my second computer.
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.
I want to implement websites using a computer that is running only Ubuntu.
This is not feasible because Ubuntu FireFox displays completely different from Windows FireFox.
This means that I can do things like JS & PHP on Ubuntu, but have to switch to my Windows Computer to (edit and) view HTML & CSS as they appear for most users.
This makes file management too complicated. I have two of everything. And...I don't want to install a server on my Windows machine.
Is there any browser that looks remotely similar between Ubuntu and Windows? I want to stay on Ubuntu as much as possible.
Following the advice from Greg, why don't you install wine and run Internet Explorer from that?
use Wine to run a windows based browser to work with: http://www.winehq.org/
If its layouts and stuff you're worried about have a look at http://browsershots.org/ it allows you to see what a website looks like on many revisions of many browsers on BSD, Linux, Windows and Mac
I have to say you are working on the total wrong idea.
I can easily switch between 20 different themes. I'm currently using either an old Win2000 theme or the olive WinXP theme.
The only way for a non Desktop GUI app is to make your website look good on any computer.
Use CSS to style the input elements. Or better - make the GUI simple enough that the look of the common GUI form controls do not matter.
Everything else should work exactly the same anyway cause the layout engines for Firefox Linux and Firefox Windows are the same.
Google Chrome took special care to look the same on all platforms for font-rendering, etc. But I haven't noticed anything problematic on firefox, either. Have you installed msttcorefonts on ubuntu? That should help.
I agree with Greg. The simplest problem from one OS to another is fonts. While you can installed Microsoft licenced fonts in linux out of the box this isn't the default eg. Arial.
Even then just look at Safari for windows verusus Safari for Mac. Apple has their own implementation of the licenced MS fonts, as such the same font (eg arial) on Windows is not the same as on Mac. This can also be the case on linux if a slightly different implementation of the font is installed.
That aside, all the chrome ( toolbars, buttons, titlebar etc ) are different from one OS to another, so if you're a good developer and try really hard to word your content and fit your layout so that most people don't have to scroll just for two or three lines, then without actually viewing the page in the target OS you're really just doing half the job.
If you can get your head around it, try something like virtualbox and have a set of virtual machines, which you can run one at a time and test fully how each browser will work with your pages. A few things to note: as much as we ALL hate IE6, if your sites are going to be viewed by a company / organisation, chances are they'll still be on IE6, even worse is that there are TWO versions on IE6 which do operate slightly differently, notiable IE6 from XP ( no service packs installed ) and IE6 from XP SP2. Then you've got the default install that is Vista with IE7 ( which can look different and operate differently to IE7 on XP), and the default install in Win7 which is IE8. REALLY importantly is that it is known that some CSS on IE8 in XP is different to IE8 on Vista or Win7.
We (unfortunately) have as part of our testing 7 Win vm's to test just IE, then two for Firefox on windows ( FF 3.0 and 3.x - the latest ) plus two vms for Chrome and two vms for Safari on windows. Admittedly we promise our sites will work on all these browsers in our projects if the client chooses to at an additional cost.
Good luck
Fonts and platform form controls are likely reasons that you're going to see things differ between Linux and Windows. But they can also cause differences between different Windows users or different Linux users, so testing on a single Windows machine isn't necessarily sufficient either. If you're seeing drastic differences between Linux and Windows, it might be a sign that there are things in your design that are unnecessarily dependent on particular text widths or form control sizes.