I've been working quite a lot with the com0com driver. Its mostly been great - thanks! There are a few minor things we've discovered and could use some help on.
1) We've found that writes to a COM0COM port when the partner is down does not behave the same as a real serial port. An application (really an OLE COM component) that we don't control expects writes to complete normally (returning good rc and n bytes written). com0com completes the first write (very first) like a real port does but subsequent writes timeout and return 0 bytes written. The app doesn't use hardware flow control and pays no attention to modem status. A real port essentially transmits to nowhere and completes the writes. This is our biggest issue. I'm a driver programmer and could take a stab at fixing this myself, but com0com isn't trivial and I wonder if this is something that would be easy to fix for you and if you'd be willing to fix it.
2) Trying to work around the first issue, we tried using PluginMode for the port that the app opens. This worked on Windows XP and Server 2003 but it doesn't work on Windows 2000 Server with terminal server. I'm pretty sure that the problem is with the fact that ShowPort() runs in the context of the pnp manager (system) and that the symbolic link is created in the global namespace instead of the local namespace. This is a documented fluke in how windows 2000 works. I haven't tried, but I think adding a call to IoCreateSymbolicLink from the open routine (if running windows 2000) would fix the problem. Also, the link would need to be removed in the close routine.
3) What level of Windows DDK do you use? I'd feel a lot safer if I could first build a matching driver to the one you build. Everything I've tried builds and runs but something is significantly different -> my checked builds come out smaller than your supplied binaries.
4) Silent Uninstall -> setup.dll has a pop-up that makes it impossible to do silent uninstalls (uninstall /S). I've made this modification for our purposes (but I'd feel better if it was in the base).
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
1) Set EmuBR=yes and EmuOverrun=yes parameters.
2) Could you send me detailed instruction how to
reproduce PluginMode problem.
3) DDK 3790.1830, setenv.bat W2K chk
4) Fixed in CVS.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
You have to have Windows 2000 Server with Terminal Services. Setup a com port pair, for example COM41, COM41B with COM41 configured with PluginMode=y. Write a test program that first opens com41b, then com41. Remote desktop into the server and try to run the test program and it fails. If you run the test program from the server console, it will work.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I tried to test it by hand (with hyperterminal) and it works fine.
Possible problem is because there is some delay between opening com41b and accessibility com41.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The test program was just an example to illustrate the problem (or to try). When we do what you did with hyperterminal, we have the problem. What could the difference be?
1. The issue we have is specifically with Windows 2000 Server with the Windows Terminal Services component added. Ours is Windows 2000 Server SP4. The problem does not happen on Windows XP or Windows Server 2003.
2. The issue only occurs when you remote desktop into the Window 2000 Server from another computer (in my case, the client is an XP Pro client). The problem doesn't happen if you use the screen/keyb/mouse that is physically connected to the machine.
Can you confirm that you are running the same scenario (RDP into the windows 2000 server SP4)?
I believe there are some tools around here that will allow me to view the device tree. If our setups are confirmed to be the same, I'll try and find those tools and see if I can come up with another way to show what's going on.
Thanks for your help so far.
Dennis
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The possible workaround is to start a terminal server
session while the port is not hidden (that was my
yesterday's mistake :).
For example:
1. open first terminal server session and open com41b
with hyperterminal
2. open second terminal server session
3. close com41b and first terminal server session
4. use com41b and com41 in the second terminal server
session
I don't like to add a call to IoCreateSymbolicLink from
the open routine because it will not fix the problem if
the paired ports are used in the different sessions.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The workaround you suggest isn't possible in our scenario, unfortunately.
As for the IoCreateSymbolicLink from the open routine -> what I was thinking was keeping your existing call but also adding an additional call in the open routine. To be safe, I would only do this only if running on Windows 2000. Its not perfect but its an improvement. It seems more likely that the port pair would be accessed by two programs in the same session than two programs in different sessions, so this would help in the most likely of cases.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I've been working quite a lot with the com0com driver. Its mostly been great - thanks! There are a few minor things we've discovered and could use some help on.
1) We've found that writes to a COM0COM port when the partner is down does not behave the same as a real serial port. An application (really an OLE COM component) that we don't control expects writes to complete normally (returning good rc and n bytes written). com0com completes the first write (very first) like a real port does but subsequent writes timeout and return 0 bytes written. The app doesn't use hardware flow control and pays no attention to modem status. A real port essentially transmits to nowhere and completes the writes. This is our biggest issue. I'm a driver programmer and could take a stab at fixing this myself, but com0com isn't trivial and I wonder if this is something that would be easy to fix for you and if you'd be willing to fix it.
2) Trying to work around the first issue, we tried using PluginMode for the port that the app opens. This worked on Windows XP and Server 2003 but it doesn't work on Windows 2000 Server with terminal server. I'm pretty sure that the problem is with the fact that ShowPort() runs in the context of the pnp manager (system) and that the symbolic link is created in the global namespace instead of the local namespace. This is a documented fluke in how windows 2000 works. I haven't tried, but I think adding a call to IoCreateSymbolicLink from the open routine (if running windows 2000) would fix the problem. Also, the link would need to be removed in the close routine.
3) What level of Windows DDK do you use? I'd feel a lot safer if I could first build a matching driver to the one you build. Everything I've tried builds and runs but something is significantly different -> my checked builds come out smaller than your supplied binaries.
4) Silent Uninstall -> setup.dll has a pop-up that makes it impossible to do silent uninstalls (uninstall /S). I've made this modification for our purposes (but I'd feel better if it was in the base).
1) Set EmuBR=yes and EmuOverrun=yes parameters.
2) Could you send me detailed instruction how to
reproduce PluginMode problem.
3) DDK 3790.1830, setenv.bat W2K chk
4) Fixed in CVS.
Recreate for issue#2:
You have to have Windows 2000 Server with Terminal Services. Setup a com port pair, for example COM41, COM41B with COM41 configured with PluginMode=y. Write a test program that first opens com41b, then com41. Remote desktop into the server and try to run the test program and it fails. If you run the test program from the server console, it will work.
I tried to test it by hand (with hyperterminal) and it works fine.
Possible problem is because there is some delay between opening com41b and accessibility com41.
The test program was just an example to illustrate the problem (or to try). When we do what you did with hyperterminal, we have the problem. What could the difference be?
1. The issue we have is specifically with Windows 2000 Server with the Windows Terminal Services component added. Ours is Windows 2000 Server SP4. The problem does not happen on Windows XP or Windows Server 2003.
2. The issue only occurs when you remote desktop into the Window 2000 Server from another computer (in my case, the client is an XP Pro client). The problem doesn't happen if you use the screen/keyb/mouse that is physically connected to the machine.
Can you confirm that you are running the same scenario (RDP into the windows 2000 server SP4)?
I believe there are some tools around here that will allow me to view the device tree. If our setups are confirmed to be the same, I'll try and find those tools and see if I can come up with another way to show what's going on.
Thanks for your help so far.
Dennis
Ok. I reproduced the problem.
The possible workaround is to start a terminal server
session while the port is not hidden (that was my
yesterday's mistake :).
For example:
1. open first terminal server session and open com41b
with hyperterminal
2. open second terminal server session
3. close com41b and first terminal server session
4. use com41b and com41 in the second terminal server
session
I don't like to add a call to IoCreateSymbolicLink from
the open routine because it will not fix the problem if
the paired ports are used in the different sessions.
The workaround you suggest isn't possible in our scenario, unfortunately.
As for the IoCreateSymbolicLink from the open routine -> what I was thinking was keeping your existing call but also adding an additional call in the open routine. To be safe, I would only do this only if running on Windows 2000. Its not perfect but its an improvement. It seems more likely that the port pair would be accessed by two programs in the same session than two programs in different sessions, so this would help in the most likely of cases.