We get an app that was working fine until update Windows from Vista Home Basic to 7 Home Premium. We use mscomm32.ocx to control serial port, but it seems it's not supported for 64 bits OS.
Each time we try to read the port: Thisform.msCommControl.Input We got the following:
OLE IDispath exception code 0 from MSComm: Error reading comm devide
We've made a lot of unsuccessful tests. Does any one know how to fix this problem?
The solution is to use an updated control that is contantly under development so newer Windows are also supported. ADONTEC's SuperCom ActiveX is a MSComm compatible ActiveX that developers use for many years in order to replace the MSComm. It is compatible with 32 and 64 bit of Windows 2000/XP/7/8 and Windows 10. You are almost done in few minutes. In many cases the application runs not only faster but is by far more stable and it also offers by far more functionality. See more info here.
that MSCOMM32.OCX will not work with Windows 7 64 bit machines. However, strange as it may seem I have a VB6 program controlling equipment from a virtual comm port (USB ~ serial converter)
It works fine on windows 8.64 bit machine.
The only thing is that the converter driver had to be modified to run on 64 bit.
If you are using a real com port that doesn't matter.
Try it on a 64 bit machine with Windows 8
Related
I'm having an issue with a bit of boost compute code that I have running on two machines. My dev machine is running windows 7 using a radeon WX9100 gpu, and everything is running fine. Another lab machine I am using is nearly identical, but is running windows 10 and has the windows 10 version of the radeon driver.
The windows 7 machine shows the openCL device name being "GFX900" and the windows 10 machine shows the name as "GFX901". A bitcoin mining site i found said this is fine for that model.
What is not fine is that the boost compute/opencl memory buffers do not free from device memory on the windows 10 machine, even (especially) if i use "BUFFERNAME.~buffer()".
Im thinking this might be a driver issue, but I'm really not sure.
Thanks in advance for any help!
Eric
Actually we are running a x86 Windows Desktop C++ Qt application with HTMLHelpCtrl.ocx ActiveX control (all modules x86) in order to call the .chm HtmlHelp of the application.
Now we want to port our application to x64. Unfortunately it is not possible to use the current x86 HTMLHelpCtrl.ocx directly. Is there a 64 bit version of HMTLHelpCtrl.ocx available? Or what is needed to be able to use the x86 ActiveX control in x64?
We already tried to do it this way: Using a 32-bit COM Object from a 64-bit Application. But this is not an option, because we have the requirement to make it work without administrative rights. Therefore we cannot change the registry values mentioned in the article.
The solution is rather simple: you need to perform the steps that you refer to in your installer. That's where you will have the administrative rights needed, and that's where such things are meant to be handled.
If you can't, then you need to split your application into two processes: one that is 32 bit, and another that is 64 bit. Host the 32 bit object in the 32 bit process, and run the stuff that needs large memory in the 64 bit process.
I've been trying to research why certain compatibility features differ based on operating system so I can program a patch. I'm using the compatibility settings in the registry for Windows 95 to run a game (that of which the game was produced on) in each system. In Windows XP, the game runs perfectly. None of the scenes lag, and the sound works just as well as the scenes. I'm unsure of how it runs in Windows Vista, but in Windows 7 & 8 the compatibility feature breaks the game. I used a VM to run XP, but that doesn't effect the game's playability; real XP users have tested it. Whenever I play the game using the Win95 setting for compatibility in 7 & 8, everything lags. The music doesn't slow down during gameplay, but the graphics do. During cutscenes, they literally break. Everything pixelates, white noise and static increases volume, and the video lags every two seconds.
I therein tested it in Ubuntu Linux via WINE, and it runs better than it does in XP. I just had to use the alsa sound driver. What changed? If so, is it programmatically fixable? I'm using an amalgamation of C++, Batch and Java.
If it is necessary, the video game is entitled "The Neverhood."
Thanks.
The compatibility feature available in the shell is just scratching the surface of the "Application Compatibility" subject in Windows.
There is a tool called "Microsoft Application Compatibility Toolkit (ACT)" (that exist since Windows XP exist I believe) that has much more to offer, so maybe that can help.
For example here are some compatibility settings for Graphics Control Issues
I currently play "The Neverhood" on Win7 x64 without any visual problem, you are right when I played on Win7 for first time (4 years ago) was a headache and a little tricky to do the correct compatibility flags for each win version but finally I wrote this reg code for Win7 and worked for me while 4 years, sure it will work for you too:
Windows Registry Editor Version 5.00
[HKEY_CURRENT_USER\Software\Microsoft\Windows NT\CurrentVersion\AppCompatFlags\Layers]
"C:\\Folder\\nhc.exe"="# WIN95 256COLOR 640X480 DISABLEDWM"
Where "C:\\Folder\\nhc.exe" of course is the path to your Neverhood. (Notice the double backslashes)
that flags means: Change Display color to 256 colors, change display resolution to 640x480, disable Themes service (DWM Service).
I hope this help you.
This may not answer the question directly, but if you want to improve performance of The Neverhood, change the compatibility to run in Windows 95 - then switch all other options ON, except the bottom three. This helps to make the game as fast and smooth as possible.
I just implemented a system-wide hook; it hooks into 32-bit processes and reverses their text (eg. hooks into textpad and reverses menu text etc., just to get some basic hooking going). I posted my code here:
Having trouble with microsoft detours
It works fine for textpad, chrome etc., but when I try to use it on the one program I really need, a java application, the application freezes. The program itself appears unaffected; no strange error codes or anything. It's the application (which is my broker's trading platform) that freezes. It's a .jnlp file that is launched via the java web-starter (which subsequently loads up the trading platform). It launches as a 32-bit process usng jre6.
I am running Windows 7 64-bit, Visual Studio 10.0, Detours 3.0. This is pretty unfamiliar territory for me; not sure how to proceed or how to debug this issue. I'm not married to the approach I used; if I could circumvent this issue with a different kind of hook I would gladly use that. Any idea how I can solve/debug this issue? Any help is appreciated.
UPDATE: Tried this on Intellij (a java IDE) and it freezes that too. I wondered if maybe it was just the fact that these applications load a ton of processes so maybe that was mucking things up, but tried it on Adobe Photoshop Elements (also loads a ton of processes) and it worked fine on that. So still stuck.
When you hook a process, you need to use 32 bit hook to hook a 32 bit process. Since you use VS 2010 64 bit, Have you set up your solution to generate a 32 bit hook?
Your target is a Java application. You may want to try the Java Accessibility to attch to the process and then use reflection to get the text and reverse it.
Good luck
As the title says, I'm experiencing very poor performance of the printf call in our code. It's used pretty extensivly for debugging purposes and hasn't caused an issue for the most part, but when I brought our code up on my new laptop (17" Macbook Pro 2011) under Windows 7 Professional 64 bit it slows down everything. I profiled the app with VerySleepy and sure enough it is the printf call that is causing the slow down, but I cannot for the life of me figure out why.
My original thought was that I was running a 32 bit app under a 64 bit os, but I'm not the only one in the office running Windows 7 64 bit (not sure the exact version of the others)
Any insight would be greatly appreciated.
EDIT: forgot to mention I'm using Visual Studio 2008 Professional
Make sure you got the latest and greatest graphics processor drivers on your box. If your printfs go to screen then bad drivers will kill performance.