An application, consists basically on a communication between a microcontroller and a pc, is running perfectely on Windows 7 64 bits. Since i have windows 10 installed, the application doesn t work anymore. Even the serial communication isn t established. ( an error shown that the application can not establish the communication)
I have verified the microcontroller with other Terminal running on Windows and no Problem within. Also i think that the Problem could be on the Code, the application was created with visual Studio, well i don t have any experience with visual Studio,so that i would ask you if there is a way to check that this application for instance will not work on Windows 10!
Thank you in advance
You indicate that the application will run, therefore it is unlikely that the application is incompatible with Windows 10. You're getting an error saying that the application is unable to communicate with the serial port, so the application is opening. Most applications which flat out won't work with Win 10 use older, unsupported versions of .Net or expect a FAT filesystem and simply won't run.
This suggests that Windows 10 did not have a native driver for your serial port. This is not too shocking; the older pin serial ports currently see exclusive use and are replaced (for most users) by USB-connecting components. I would check the computer's Device Manager. If you don't see any serial ports there, or see them but with an error, Win 10 probably did not have the driver required. From there I would contact the motherboard or serial bus card manufacturer for updated drivers, if they exist.
Related
Our Delphi Win32 application has been successfully pairing Bluetooth devices (using the Windows Bluetooth API) with the computer and using the resulting serial port. After installing Windows 10, the virtual serial port resulting from the pairing cannot be opened. Our application can see the new com port but when it tries to open it, error 1168 (ERROR_NOT_FOUND) occurs.
I can see the com port has been created in Windows as well (associated with the same device serial number I am trying to connect to). The com port is the same as what my application has been trying to open.
Tried exiting my application and using a trusted terminal program (to guarantee that the port will be available). it can't open the port either.
It makes me wonder whether Windows 10 is doing some new, aggressive power saving in respect to the Bluetooth radio.
Upgraded a laptop from Win 7 to Win 10; same result. that's both computers upgraded to Win10 showing the same problem.
Made a C# app with Visual studio 2013; same result.
Any ideas why I would get error 1168 when trying to open the port?
Thank you!
I have been told Windows 10 has an all-new Bluetooth stack.
This new stack only supports SPP 1.2. We needed 1.1 supported.
Migrating to RFCOMM.
I'm manufacturing a device that connects to my computer using Bluetooth and then a desktop Java app uses the Bluetooth connection to send serial data to the device which is then displayed.
When I try to connect my device to windows 7 it successfully finds and pairs with it creating a Bluetooth link on a COM port. This link can then be used by a serial prompt (used for testing) or my Java application. It works initially however soon after windows drops the connection and the only way to reconnect is to delete the device within devices and printers and then reconnect.
This seems to be a known problem with windows bluetooth so I decieded to use a third party Bluetooth application. I downloaded and tried Toshiba's Bluetooth Stack and it was able to add a Bluetooth device and keep a stable connection which works great however this only works for Toshiba computers without getting a cracked version.
This device is commercial and can't be sold with cracked versions of software. Has anybody experienced the same problems or not in other operating systems and has any solutions of advice as that would be a tremendous help.
This is not a good idea/method to use the COM ports generated by Windows, it's not working fine and not reliable in any scenario ; you should use Bluetooth Sockets instead.
Using Toshiba or Widcomm or BleuSoleil won't help: under Win7, all dongles are now trying to use the Microsoft Stack, not their own implementation.
I currently have a 32-bit PowerBuilder application that we are trying to port over to a Windows 7 64-bit environment. Realizing the obvious that PowerBuilder 10.5 was built previously before Window7 came out and the big also the obvious fact that this application was built within a Windows XP 32-bit environment.
The 32-bit PowerBuilder application spits out the following error message when deployed on a Windows 7 64-bit machine.
Application Terminated. Error: Invalid DataWindow row/column specified at line 44 in function ivvisiblecolumn of object objectwindow
The database profile setup points to an OLEDB and the backend database is MSSQL 2008. Currently the application does run on the Windows7 64-bit environment and seems to be working in an inquiry mode only. Meaning we can read some of the records on the datawindow, but as soon as you try to make a transaction it blows up.
My question is - Is it possible to get a 32-bit app working in a 64-bit environment?
So far the client is asking to come up with possible solutions without the idea of upgrading to PowerBuilder 12.5. Essentially they want to stay at 10.5 but yet get the app working from a 32-bit environment to a 64-bit...apples to oranges if you know what I mean. Further investigation is needed into whether the code will not function in 64bit or dll issues with powerbuilder client runtime in 64bit. They are really trying to stay away from any app rewrite since the application is older than when Christ was a carpenter. The app was originally built in PB 6.5 I think.
So far I have the following ideas but I am new to this:
- I understand that Windows 7 comes with a virtual machine IIRC. I think it's called WOW64. Is it possible to create a virtual on a server and have the users run a 32-bit application inside a 64-bit machine? Then create a shortcut of somekind for the user to simply click on?
We do have a virtual XP machine and a virtual Windows7 64 bit machine for testing. PowerBuilder 10.5 actually installed on Windows 7 and seems to be working fine. However running the application in run mode or debug causes many errors as you can imagine.
The application has been built in XP and run on Windows 7, but the results yeild the above error message.
I have not looked yet into the Run under Compatibility mode, but I am told by the team it will not work.
I have not looked at UAC or ALC User management yet. Could that be something affecting the 64-bit system?
I know this is app unrelated but...I have seen in some cases 32-bit applications work in a windows 64-bit environment by simply targeting certain DLL files. An example case is Microsoft Flight Simulator X where the 32-bit game would crash in windows 7 64-bit. The solution for that was to simply go get a Vista 64-bit DLL file called uiautomationcore.dll and copy that into the windows environment. The Games also have to be installed on the root of C: in order to work.
Does anyone have any recommendations on how I can approach this problem?
I apologize If I'm vague in my notes here.
UPDATE: Has anyone had any experience with PB 10.5 runtime files on a 64 bit machine? I am wondering if the powerbuilder client runtime is installing its dlls into the correct location of the application C:\XXX or can't find it? Wondering how to approach this.
Basically nothing should prevent a 10.5 PB app to run on Win7/64. I develop and run several products in PB11.5 (also a 32bit IDE) on a win7/64. And btw, some older PB like 9 still run on Win7, so is likely PB6.5. The problem must be elsewhere, relative to the app design.
WoW64 (and Wow6432Node in the registry) is not a true VM, it's a bunch of services and system API hooked with fallbacks for 32 bit applications (and legacy applications that do not conform to the novelties introduced since Vista)
Error: Invalid DataWindow row/column specified at line 44 in function ivvisiblecolumn of object objectwindow sounds typically like an incorrectly handled return value (where a computed row number is getting negative or null before trying to access a property or data at that given invalid row), or it could be relative to the way to get back an autoincrement value from the db after an insert
beware of the UAC management that could lead to unexpected behavior with legacy application, especially if the application is using a database: the UAC guidelines tells not to install data managed by the application in the Program Files folder that is now Read only (since Vista - that guideline is since XP). Instead you must put that into a ProgramData sub-directory if it is accessible by everyone and into a user local AppData if the data is just for the current user. Win7/Vista can silently conforms to the standard by duplicating the data locally to the user (in the Users\username\AppData\Local\VirtualStore) while still pretending to the application that it is currently accessing it from Program Files...
you could give a try with Dependency Walker to look for the incorrect dll problems
We moved many of our applications to Windows 7 64bit. The only issue we ran into was with the database connections. You are running a 32bit application so you need to connect to 32bit database. If you bring up "Data Sources (ODBC)" from the control panel, you will be looking at the 64 bit entries. You need to use the 32 bit ODBC found in "C:\Windows\SysWOW64\odbcad32.exe". The Registry entries you need are in the following locations...
HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\ODBC\ODBCINST.INI
HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\ODBC\ODBCINST.INI\ODBC Drivers
HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\ODBC\ODBC.INI
HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\ODBC\ODBC.INI\ODBC Data Sources
or
HKEY_CURRENT_USER\SOFTWARE\Wow6432Node\ODBC\ODBCINST.INI
HKEY_CURRENT_USER\SOFTWARE\Wow6432Node\ODBC\ODBCINST.INI\ODBC Drivers
HKEY_CURRENT_USER\SOFTWARE\Wow6432Node\ODBC\ODBC.INI
HKEY_CURRENT_USER\SOFTWARE\Wow6432Node\ODBC\ODBC.INI\ODBC Data Sources
I need to set up USB communication between a Windows 7 host and a Linux device for data transfer. I was able to compile the Linux kernel on the device to include the Gadget Zero driver in the kernel (not as a loadable module - Linux version 3.0.15). My project has some requirements, which also explains why I chose Gadget Zero:
1) On the Windows 7 host, a kernel mode driver must be used to communicate over the USB connection for sending and receiving bulk data. (speed is not important, not a lot of data at once).
2) On the linux device, no requirements on USB side except send and receive data easily over USB link. The data received will eventually be "unmarshalled" to call functions in another kernel module (and those responses packaged and sent back to the host).
3) Multiple linux devices will be connected to the host, so need easy way to enumerate connected devices and communicate with them.
So due to the requirements, I decided against the Gadget Serial. I'm having serious issues sending and receiving data over the virtual COM port in kernel mode (KMDF) in Win 7 host. WinUSB does not seem to want to open my attached device (I'm using KMDF windows USB driver from template in VS2012) Also, the gadget serial driver on the linux side, I cannot find the functions where the data is received and sent. Plus, any received data on the linux device seems to be echoed back to the host for some reason. (and to test this, I wrote a simple user-mode app in Windows, which is a no-no for my project).
Gadget Zero, it appears much simpler on the linux side. I can plug the USB cable to the Win7 host, and I can get the device to appear in the device manager. However, again I am having problems with getting communication going over the link. Gadget Zero has 2 bulk endpoints, so this shouldn't be an issue. Surely, someone has made data communication possible between a Windows host and a linux device using Gadget Zero? With Gadget Zero, it should be easy to enumerate the connected linux devices and communicate with them.
The trick is to keep the Windows side communication in kernel mode. Can someone point me in the right direction perhaps with Gadget Zero, Windows 7 KMDF, and some sample source code? I have a hard time believing no one has done this before because my internet searches don't turn up much. (and mostly user-mode solutions with Gadget Serial).
Thanks!
So you're writing a Win32 driver in which you want to communicate with your linuxed usb? I haven't written much win32 kernel code, but I believe I've seen a huge section in the doc, saying something like "This is how you make usb drivers"... That'd be it. In other words, when in kernel mode you have access to the full kernel usb layer. You don't need an existing driver or whatnot.
On the linux side you can use the serial gadget, in a different run mode. Only the default run mode, registers it self as VCP. There exist a more basic mode:
modprobe g_serial use_acm=0
Give it your own vendor id and you'll be able to attach your very own custom win32 driver. The 'multiple linux devices' will be handled by Windows. (Multiple instances of your driver, will be initiated.)
The echo you're seeing btw, is most likely a terminal feature. (The terminal mode on uarts will echo.) You have to disable it, when connecting. And now that you're at it, you also have to disable the xon/xoff, esc chars etc. (Standard legacy rubbish.)
And another thing. I'm not sure the gadget zero actually sends the data onto the line. It's meant for testing the gadget framework. (I could be mistaken though.)
Anyway, you've prolly solved this issue years ago. I'd be nice to know what you came up with.
I'm developing a project that has a number of hardware sensors connecting to the deployment machine through RS232 serial ports.
But ... I'm developing on a machine without an physical RS232 serial ports, but I would like to make fake serial ports that I can connect to and output data from with the aim of faking input from hardware sensors.
Does anyone know of a way to create a fake serial port and control it on Windows XP?
If you are developing for Windows, the com0com project might be, what you are looking for.
It provides pairs of virtual COM ports that are linked via a nullmodem connetion. You can then use your favorite terminal application or whatever you like to send data to one COM port and recieve from the other one.
EDIT:
As Thomas pointed out the project lacks of a signed driver, which is especially problematic on certain Windows version (e.g. Windows 7 x64).
There are a couple of unofficial com0com versions around that do contain a signed driver. One recent verion (3.0.0.0) can be downloaded e.g. from here.
I know this is an old post, but in case someone else happens upon this question, one good option is Virtual Serial Port Emulator (VSPE) from Eterlogic
It provides an API for creating kernel mode virtual comport devices, i.e. connectors, mappers, splitters etc.
However, some of the advertised capabilities were really not capabilities at all.
EDIT
A much better choice, Eltima. This product is fully baked. Good developer tech support. The product did all it claimed to do. Product options include both desktop applications, as well as software development kits with APIs.
Neither of these products are open source, or free. However, as other posts here have pointed out, there are other options. Here is a list of various serial utilities:
com0com (current)
com0com - With Signed Driver (old version)
Yet another place for com0com with Signed Driver (Pete's Blog)
Tactical Software
Termite
COM Port Serial Emulator
Kermit (obsolete, but still downloadable)
HWVSP3
HHD Software (free edition)
I use com0com - With Signed Driver, on windows 7 x64 to emulate COM3 AND COM4 as a pair.
Then i use COM Dataport Emulator to recieve from COM4.
Then i open COM3 with the app im developping (c#) and send data to COM3.
The data sent thru COM3 is received by COM4 and shown by 'COM Dataport Emulator' who can also send back a response (not automated).
So with this 2 great programs i managed to emulate Serial RS-232 comunication.
Hope it helps.
Both programs are free!!!!!
There's always the hardware route. Purchase two USB to serial converters, and connect them via a NULL modem.
Pro tips:
1) Windows may assign new COM ports to the adapters after every device sleep or reboot.
2) The market leaders in chips for USB to serial are Prolific and FTDI. Both companies are battling knockoffs, and may be blocked in future official Windows drivers. The Linux drivers however work fine with the clones.
Another alternative, even though the OP did not ask for it:
There exist usb-to-serial adapters.
Depending on the type of adapter, you may also need a nullmodem cable, too.
They are extremely easy to use under linux, work under windows, too, if you have got working drivers installed.
That way you can work directly with the sensors, and you do not have to try and emulate data.
That way you are maybe even save from building an anemic system.
(Due to your emulated data inputs not covering all cases, leading you to a brittle system.)
Its often better to work with the real stuff.
i used eltima make virtual serial port for my modbus application debug work. it is really very good application at development stage to check serial port program without connecting hardware.