TCL fails to open bluetooth serial port

[Philip Hoffman]

Hello all,

Here is my delimma. I'm running the Activestate binary distribution of TCL 8.6.1. For whatever reason I cannot open bluetooth serial ports using the standard windows driver with TCL. Using Tera Term the port will open right up. I've tried these commands:

% open //./COM7 r+
couldn't open "//./COM7": invalid argument

% open \\\\.\\COM7 r+
couldn't open "\\.\COM7": invalid argument

% open COM7 r+
couldn't open "COM7": invalid argument

However opening hardware serial ports or usb serial ports is never an issue:

% open COM1 r+
file33a4ac0

I did find a patch, but am unsure if it applies to this or not. In addition I would not have a clue of how to apply the patch.
http://sourceforge.net/p/tcl/patches/578/

Any ideas?

[Óscar Fuentes]

open com4: r+

(note the double-colon) works for me on Windows XP with ActiveState
8.4.13 for sending data to a Bluetooth printer.

[Philip Hoffman]

Still no luck. the return error is a little different though.

% open COM7: r+
couldn't reopen serial "COM7:": invalid argument

I'll try 8.4 but I really need 8.6 for a lot of other features that I'm using.

[Harald Oehlmann]

Dear Philip,

unfortunately, we have sometimes the same issue.
We normally conclude buggy VCOM drivers.

I have traced the syscalls (by HDMon) and TCL just calls more than Putty.
If the open fails, there is IMHO no way but a bluetooth driver update.

I have seen what the proposed patch does.
I would be in favor of this patch but I did not see this issue for a long time now.

There are three common stacks which work:
- Broadcom: never a problem
- Toshiba: Small write buffer, write slowly
- Microsoft:
If it connects, set serial buffer size to 0 !
fconfigure $h -buffersize 0

It is true, that TCL 8.4 did sometimes work better here.
Things in versions changed quite a lot under the hood...
I am also using tcl8.6.1

I would be ready to work with you including the patch.
Maybee Alexandre Ferrieux or Andreas Kupries may say something on this issue.

The current reference to the patch is:
http://core.tcl.tk/tcl/tktview?name=2413550

Sorry,
Harald

[Philip Hoffman]

Well I don't know anything about how to apply a patch. I'm guessing this would involve compiling TCL. I'm willing to learn but am definitely new to all of this.

Is there a reason the patch never made it into the Activestate binaries?

[Philip Hoffman]

Well I still don't know what I'm doing but I did manage to compile TCL 8.6.1 using VC10. Next time I'll modify the source with the patch and see where that gets me.

[Harald Oehlmann]

Am Donnerstag, 30. Januar 2014 00:12:12 UTC+1 schrieb Philip Hoffman:
> Well I still don't know what I'm doing but I did manage to compile TCL 8.6.1 using VC10. Next time I'll modify the source with the patch and see where that gets me.

The main point we have to keep is that you should be able to test it.
I don't have any test possibilities any more.
We should first patch 8.5.14 and then migrate to 8.6.1 (which is the usual way).

Which windows do you use ?

Harald

[Harald Oehlmann]

I have applied the patch to tcl8.5:

http://core.tcl.tk/tcl/info/84307fe13f

Could you try if it solves the issue ?

For me, many tests fail and there will be much work, but first try it.

I can also provide a binary for Win32 I can send by E-Mail.
Look for HaO on the wiki for my address.

Harald

[Harald Oehlmann]

Am Donnerstag, 30. Januar 2014 12:07:37 UTC+1 schrieb Harald Oehlmann:
> http://core.tcl.tk/tcl/info/84307fe13f

After have cleaned up the manifest issue with Jan of the 8.5. branch in general:

http://core.tcl.tk/tcl/info/5ef480c185

Now, the test suite passes as in tcl8.5.15 release.

Philip, IMHO ready for a test ;-)

Harald

[Philip Hoffman]

Hmmm well still no go. I'll email you for the binary but based on the faster times opening the physical ports I have to believe the code is not attempting to re-open the port.

Here's some more information:

The bluetooth to serial converter based of the Roving Networks RN-42 bluetooth on a chip.

I'm running Windows 7 64-bit and use 32 bit TCL binaries.

Probing the connection status of the bluetooth component with my oscilloscope I can see that the status becomes connected and then quickly disconnects (PIO2 goes high for ~20ms) For connecting with Teraterm it connects and stays connected according to the connection status pin.

Is there a way I can put a breakpoint in the tcl C code so that we could possibly determine what the cause might be?

[Harald Oehlmann]

Am Donnerstag, 30. Januar 2014 17:37:02 UTC+1 schrieb Philip Hoffman:
> Hmmm well still no go. I'll email you for the binary but based on the faster times opening the physical ports I have to believe the code is not attempting to re-open the port.

It was a try...
I use the HHD "free serial monitor" to check what software does.
Unfortunately, it is not downloadable any more and works probably only on 32 bit...

> Here's some more information:
>
> The bluetooth to serial converter based of the Roving Networks RN-42 bluetooth on a chip.

The point is not the bluetooth chip but the used windows stack.
Look to the device manager and see the copyright notices of the drivers...

> I'm running Windows 7 64-bit and use 32 bit TCL binaries.

Ok.

> Probing the connection status of the bluetooth component with my oscilloscope I can see that the status becomes connected and then quickly disconnects (PIO2 goes high for ~20ms) For connecting with Teraterm it connects and stays connected according to the connection status pin.

Ok, electrical engenier like me ;-)

> Is there a way I can put a breakpoint in the tcl C code so that we could possibly determine what the cause might be?

If you compile with debug symbols and you start the binary within MS Visual C, you can use breakpoints etc.
I never really did it but this might be really good...

No E-Mail received for instance...

Enjoy,
Harald

[Uwe Klein]

Philip Hoffman wrote:
> Hmmm well still no go. I'll email you for the binary but based on the faster times opening the
> physical ports I have to believe the code is not attempting to re-open the port.
>
> Here's some more information:
>
> The bluetooth to serial converter based of the Roving Networks RN-42 bluetooth on a chip.
>
> I'm running Windows 7 64-bit and use 32 bit TCL binaries.
>
> Probing the connection status of the bluetooth component with my oscilloscope I can see that the
> status becomes connected and then quickly disconnects (PIO2 goes high for ~20ms) For connecting
> with Teraterm it connects and stays connected according to the connection status pin.

what activity do you perform just after opening the BT device?
what return do you get from [fconfigure $BTdev ] ?
same for [fconfigure $BTdev -ttystatus]

>
> Is there a way I can put a breakpoint in the tcl C code so that we could possibly determine what
> the cause might be?

uwe

[Philip Hoffman]

> Ok, electrical engenier like me ;-)

That's way too much credit for me :)

> what activity do you perform just after opening the BT device?

That's the thing, I can't get the port to open. On an extremely rare occasion I get a connection and an file handle. Should I try something when I do?

I downloaded portmon but can't seem to get it to work on Windows 7 64bit. I ran Windows 7 32-bit on a virtual machine (Oracle). The failure does repeat. The bluetooth device is a USB to bluetooth device on my PC. Here's what the device manager states:

Under Bluetooth Radios

Generic Bluetooth Radio
bthport.sys - Microsoft
bthusb.sys - Microsoft
fsquirt.exe - Microsoft

Microsoft Bluetooth Enumerator
bthenum.sys - Microsoft

There are two serial ports that show up under Ports, they are similar to this:

Standard Serial over Bluetooth Link (COM3)
bthmodem.sys - Microsoft

I have an XP machine that I can get up and running. I'll try it with that and see if portmon can work. Hopefully that will give some more information.

[Philip Hoffman]

Ok so here's an update.

I was not able to get the Windows XP machine setup at the moment. I decided to look at a possible issue with the Bluetooth dongle I used. Today I went ahead and tried this on a different machine with a built-in Bluetooth module (Dell Venue 8 Pro). The failure repeated with both the Activestate 8.6.1 binaries and the binaries that contained the re-open fix provided by Harald.

I'll return to work next week and follow up. Thank you all for your support.

[Harald Oehlmann]

Am Samstag, 1. Februar 2014 21:46:14 UTC+1 schrieb Philip Hoffman:
> Ok so here's an update.
>
>
>
> I was not able to get the Windows XP machine setup at the moment. I decided to look at a possible issue with the Bluetooth dongle I used. Today I went ahead and tried this on a different machine with a built-in Bluetooth module (Dell Venue 8 Pro). The failure repeated with both the Activestate 8.6.1 binaries and the binaries that contained the re-open fix provided by Harald.

Thank you for the test. I applied the patch bliend without any functionality test. I hope, I did not make any errors.

Thanks,
Harald

[Philip Hoffman]

I got the XP machine up and running. The bluetooth dongle was plugged into the USB port and installed using the default Windows drivers. It's interesting to note that although I do get a file handle returned with the Patched TCL it does not really work. The status LEDs on the bluetooth serial device indicate that there is no connection. Any data that I send using "puts filehandle data" does not go through.

Captured information from Portmon:

Tera Term 4.78

3.64602897 ttermpro.exe IRP_MJ_CREATE BthModem4 SUCCESS Options: Open
0.00000100 ttermpro.exe IOCTL_SERIAL_GET_COMMSTATUS BthModem4 SUCCESS
0.00000050 ttermpro.exe IOCTL_SERIAL_SET_QUEUE_SIZE BthModem4 SUCCESS InSize: 8192 OutSize: 2048
0.00000179 ttermpro.exe IOCTL_SERIAL_PURGE BthModem4 SUCCESS Purge: TXABORT RXABORT TXCLEAR RXCLEAR
0.00000039 ttermpro.exe IOCTL_SERIAL_SET_TIMEOUTS BthModem4 SUCCESS RI:-1 RM:0 RC:0 WM:0 WC:500
0.00000120 ttermpro.exe IOCTL_SERIAL_GET_BAUD_RATE BthModem4 SUCCESS
0.00000055 ttermpro.exe IOCTL_SERIAL_GET_LINE_CONTROL BthModem4 SUCCESS
0.00000031 ttermpro.exe IOCTL_SERIAL_GET_CHARS BthModem4 SUCCESS
0.00000022 ttermpro.exe IOCTL_SERIAL_GET_HANDFLOW BthModem4 SUCCESS
0.12277805 ttermpro.exe IOCTL_SERIAL_SET_BAUD_RATE BthModem4 SUCCESS Rate: 9600
0.00000155 ttermpro.exe IOCTL_SERIAL_SET_RTS BthModem4 SUCCESS
0.00000070 ttermpro.exe IOCTL_SERIAL_SET_DTR BthModem4 SUCCESS
0.00000058 ttermpro.exe IOCTL_SERIAL_SET_LINE_CONTROL BthModem4 SUCCESS StopBits: 1 Parity: NONE WordLength: 8
0.00000071 ttermpro.exe IOCTL_SERIAL_SET_CHAR BthModem4 SUCCESS EOF:0 ERR:0 BRK:0 EVT:0 XON:0 XOFF:0
0.00000036 ttermpro.exe IOCTL_SERIAL_SET_HANDFLOW BthModem4 SUCCESS Shake:1 Replace:40 XonLimit:0 XoffLimit:0
0.00000058 ttermpro.exe IOCTL_SERIAL_SET_WAIT_MASK BthModem4 SUCCESS Mask:
0.00000030 ttermpro.exe IOCTL_SERIAL_SET_WAIT_MASK BthModem4 SUCCESS Mask: RXCHAR
0.00000000 ttermpro.exe IOCTL_SERIAL_WAIT_ON_MASK BthModem4

TCL 8.6b2

0.00040916 wish.exe IRP_MJ_CREATE BthModem4 SUCCESS Options: Open
0.00000026 wish.exe IRP_MJ_QUERY_INFORMATION BthModem4 SUCCESS -1169672164
0.00000123 wish.exe IRP_MJ_CLEANUP BthModem4 SUCCESS
0.00011825 wish.exe IRP_MJ_CLOSE BthModem4 SUCCESS
0.78832583 wish.exe IRP_MJ_CREATE BthModem4 SUCCESS Options: Open
0.00000191 wish.exe IOCTL_SERIAL_GET_BAUD_RATE BthModem4 SUCCESS
0.00000059 wish.exe IOCTL_SERIAL_GET_LINE_CONTROL BthModem4 SUCCESS
0.00000041 wish.exe IOCTL_SERIAL_GET_CHARS BthModem4 SUCCESS
0.00000029 wish.exe IOCTL_SERIAL_GET_HANDFLOW BthModem4 SUCCESS
0.00000138 wish.exe IRP_MJ_CLEANUP BthModem4 SUCCESS
0.07289141 wish.exe IRP_MJ_CLOSE BthModem4 SUCCESS
15.11133191 wish.exe IRP_MJ_CREATE BthModem4 TIMEOUT Options: Open

TCL 8.5.15 with Patch applied

1.86611332 tclsh85t.exe IRP_MJ_CREATE BthModem4 SUCCESS Options: Open
0.00000044 tclsh85t.exe IRP_MJ_QUERY_INFORMATION BthModem4 SUCCESS -1169672164
0.00000158 tclsh85t.exe IRP_MJ_CLEANUP BthModem4 SUCCESS
0.07298937 tclsh85t.exe IRP_MJ_CLOSE BthModem4 SUCCESS
0.00033439 tclsh85t.exe IRP_MJ_CREATE BthModem4 SUCCESS Options: Open
0.00000094 tclsh85t.exe IOCTL_SERIAL_SET_QUEUE_SIZE BthModem4 SUCCESS InSize: 4096 OutSize: 4096
0.00000111 tclsh85t.exe IOCTL_SERIAL_PURGE BthModem4 SUCCESS Purge: TXABORT RXABORT TXCLEAR RXCLEAR
0.00000029 tclsh85t.exe IOCTL_SERIAL_SET_TIMEOUTS BthModem4 SUCCESS RI:0 RM:0 RC:0 WM:0 WC:0

[Philip Hoffman]

I think I got it. After figuring out how to get Visual Studio to debug TCL I stepped through the code. I found that the getFileAttributes call to the WIN32 API was the cause of the additional open/close with the patched code. I moved the serial fix above that and it seems to be working now.

I'll still need help to get this fix to work on 8.6.

PortMon - TCL 8.5.15 with the code modification

2.13469441 tclsh85g.exe IRP_MJ_CREATE BthModem8 SUCCESS Options: Open
0.00000115 tclsh85g.exe IOCTL_SERIAL_SET_QUEUE_SIZE BthModem8 SUCCESS InSize: 4096 OutSize: 4096
0.00000177 tclsh85g.exe IOCTL_SERIAL_PURGE BthModem8 SUCCESS Purge: TXABORT RXABORT TXCLEAR RXCLEAR
0.00000038 tclsh85g.exe IOCTL_SERIAL_SET_TIMEOUTS BthModem8 SUCCESS RI:0 RM:0 RC:0 WM:0 WC:0



TclWinChan.c

/*
* [2413550] Avoid double-open of serial ports on Windows
* Special handling for Windows serial ports by a "name-hint"
* to directly open it with the OVERLAPPED flag set.
*/

if( NativeIsComPort(nativeName) ) {

handle = TclWinSerialOpen(INVALID_HANDLE_VALUE, nativeName, accessMode);
if (handle == INVALID_HANDLE_VALUE) {
TclWinConvertError(GetLastError());
if (interp != (Tcl_Interp *) NULL) {
Tcl_AppendResult(interp, "couldn't open serial \"",
TclGetString(pathPtr), "\": ",
Tcl_PosixError(interp), NULL);
}
return NULL;
}

/*
* For natively named Windows serial ports we are done.
*/
channel = TclWinOpenSerialChannel(handle, channelName,
channelPermissions);

return channel;
}

/*
* If the file is being created, get the file attributes from the
* permissions argument, else use the existing file attributes.
*/

if (mode & O_CREAT) {
if (permissions & S_IWRITE) {
flags = FILE_ATTRIBUTE_NORMAL;
} else {
flags = FILE_ATTRIBUTE_READONLY;
}
} else {
flags = (*tclWinProcs->getFileAttributesProc)(nativeName);
if (flags == 0xFFFFFFFF) {
flags = 0;
}
}

[Harald Oehlmann]

Just to be sure:
fconfigure $h -buffer 0
flush $h

-> both tried ?

At least the patch seam to do what it should, no double open, but then something goes wrong...

Just ideas,
Harald

[Philip Hoffman]

I'll give it a shot with the patched code (without the modification noted above). Just to point out the results from PortMon are only from the command:

open //./COM13 r+

[Philip Hoffman]

I tried setting the buffer to none and turning off blocking mode. Still no joy with the patch. If I put a breakpoint at the call for getFileAttributes and wait a few seconds before continuing the bluetooth device will connect and work.

I noted that changing the order didn't set the flags variable. When I was testing for just opening and closing the port everything was fine. However after attempting to send data it didn't work as expected. I initially set flags to the value defined as FILE_ATTRIBUTE_NORMAL. However this didn't work with 8.6. I still don't have an understanding of what the flag is for but I found that the hardware serial ports on my workstation would respond back with xFFFFFFFF for the getFileAttributes call so I intentially set flags to 0 and it seems to be working.

I will need help building 8.6 to the equivalent Activestate binaries. I cannot get libraries such as Itcl to work. I'm not sure why... It would definitely help with testing.

For now I made a quick test, with the patches I've attached it should work. I've tested 8.5.15 and 8.6.1 across Windows XP and Windows 7 with these devices:

proc commTest {comm loop} {
set fp [open $comm r+]
fconfigure $fp -blocking 0
fconfigure $fp -buffering none
flush $fp

puts "RX and TX (pins 2 & 3) on the serial device should be bridged"

set failCnt 0

for {set i 0} {$i < $loop} {incr i} {
set testStr "This is a test of the serial communications"
puts -nonewline $fp $testStr
after 300
set compStr [read $fp]
if {[string equal $testStr $compStr]} {
puts "Test $i Passed"
} else {
puts "Test $i Failed"
puts $compStr
incr failCnt
}
update
}
close $fp
puts "Ran $i times, had $failCnt test(s) fail"
}

I'll post the patch here for now to review

8.6.1 patch
Index: win/tclWinChan.c
===================================================================
--- win/tclWinChan.c (revision 299)
+++ win/tclWinChan.c (working copy)
@@ -95,6 +95,7 @@
static int FileTruncateProc(ClientData instanceData,
Tcl_WideInt length);
static DWORD FileGetType(HANDLE handle);
+static int NativeIsComPort(CONST TCHAR *nativeName);

/*
* This structure describes the channel type structure for file based IO.
@@ -902,6 +903,36 @@
}

/*
+ * [2413550] Avoid double-open of serial ports on Windows
+ * Special handling for Windows serial ports by a "name-hint"
+ * to directly open it with the OVERLAPPED flag set.
+ */
+
+ if( NativeIsComPort(nativeName) ) {
+
+ flags = 0;
+
+ handle = TclWinSerialOpen(INVALID_HANDLE_VALUE, nativeName, accessMode);
+ if (handle == INVALID_HANDLE_VALUE) {
+ TclWinConvertError(GetLastError());
+ if (interp != (Tcl_Interp *) NULL) {
+ Tcl_AppendResult(interp, "couldn't open serial \"",
+ TclGetString(pathPtr), "\": ",
+ Tcl_PosixError(interp), NULL);
+ }
+ return NULL;
+ }
+
+ /*
+ * For natively named Windows serial ports we are done.
+ */
+ channel = TclWinOpenSerialChannel(handle, channelName,
+ channelPermissions);
+
+ return channel;
+ }
+
+ /*

* If the file is being created, get the file attributes from the
* permissions argument, else use the existing file attributes.
*/

@@ -919,7 +950,7 @@
}
}

- /*
+ /*
* Set up the file sharing mode. We want to allow simultaneous access.
*/

@@ -952,11 +983,15 @@
switch (FileGetType(handle)) {
case FILE_TYPE_SERIAL:
/*
+ * Natively named serial ports "com1-9", "\\\\.\\comXX" are
+ * already done with the code above.
+ * Here we handle all other serial port names.
+ *
* Reopen channel for OVERLAPPED operation. Normally this shouldn't
* fail, because the channel exists.
*/

- handle = TclWinSerialReopen(handle, nativeName, accessMode);
+ handle = TclWinSerialOpen(handle, nativeName, accessMode);

if (handle == INVALID_HANDLE_VALUE) {
TclWinConvertError(GetLastError());
if (interp != (Tcl_Interp *) NULL) {

@@ -1497,6 +1532,122 @@
}

/*
+ *----------------------------------------------------------------------
+ *
+ * NativeIsComPort --
+ *
+ * Determines if a path refers to a Windows serial port.
+ * A simple and efficient solution is to use a "name hint" to detect
+ * COM ports by their filename instead of resorting to a syscall
+ * to detect serialness after the fact.
+ * The following patterns cover common serial port names:
+ * COM[1-9]:?
+ * //./COM[0-9]+
+ * \\.\COM[0-9]+
+ *
+ * Results:
+ * 1 = serial port, 0 = not.
+ *
+ *----------------------------------------------------------------------
+ */
+
+static int
+NativeIsComPort(
+ const TCHAR *nativePath) /* Path of file to access, native encoding. */
+{
+ /*
+ * Use wide-char or plain character case-insensitive comparison
+ */
+ if (1) {
+ const WCHAR *p = (const WCHAR *) nativePath;
+ int i, len = wcslen(p);
+
+ /*
+ * 1. Look for com[1-9]:?
+ */
+
+ if ( (len >= 4) && (len <= 5)
+ && (_wcsnicmp(p, L"com", 3) == 0) ) {
+ /*
+ * The 4th character must be a digit 1..9 optionally followed by a ":"
+ */
+
+ if ( (p[3] < L'1') || (p[3] > L'9') ) {
+ return 0;
+ }
+ if ( (len == 5) && (p[4] != L':') ) {
+ return 0;
+ }
+ return 1;
+ }
+
+ /*
+ * 2. Look for //./com[0-9]+ or \\.\com[0-9]+
+ */
+
+ if ( (len >= 8) && (
+ (_wcsnicmp(p, L"//./com", 7) == 0)
+ || (_wcsnicmp(p, L"\\\\.\\com", 7) == 0) ) )
+ {
+ /*
+ * Charaters 8..end must be a digits 0..9
+ */
+
+ for ( i=7; i<len; i++ ) {
+ if ( (p[i] < '0') || (p[i] > '9') ) {
+ return 0;
+ }
+ }
+ return 1;
+ }
+
+ } else {
+ const char *p = (const char *) nativePath;
+ int i, len = strlen(p);
+
+ /*
+ * 1. Look for com[1-9]:?
+ */
+
+ if ( (len >= 4) && (len <= 5)
+ && (strnicmp(p, "com", 3) == 0) ) {
+ /*
+ * The 4th character must be a digit 1..9 optionally followed by a ":"
+ */
+
+ if ( (p[3] < '1') || (p[3] > '9') ) {
+ return 0;
+ }
+ if ( (len == 5) && (p[4] != ':') ) {
+ return 0;
+ }
+ return 1;
+ }
+
+ /*
+ * 2. Look for //./com[0-9]+ or \\.\com[0-9]+
+ */
+
+ if ( (len >= 8) && (
+ (strnicmp(p, "//./com", 7) == 0)
+ || (strnicmp(p, "\\\\.\\com", 7) == 0) ) )
+ {
+ /*
+ * Charaters 8..end must be a digits 0..9
+ */
+
+ for ( i=7; i<len; i++ ) {
+ if ( (p[i] < '0') || (p[i] > '9') ) {
+ return 0;
+ }
+ }
+ return 1;
+ }
+ }
+ return 0;
+}
+
+/*
* Local Variables:
* mode: c
* c-basic-offset: 4
Index: win/tclWinInt.h
===================================================================
--- win/tclWinInt.h (revision 299)
+++ win/tclWinInt.h (working copy)
@@ -49,7 +49,7 @@
int permissions, int appendMode);
MODULE_SCOPE Tcl_Channel TclWinOpenSerialChannel(HANDLE handle,
char *channelName, int permissions);
-MODULE_SCOPE HANDLE TclWinSerialReopen(HANDLE handle, const TCHAR *name,
+MODULE_SCOPE HANDLE TclWinSerialOpen(HANDLE handle, const TCHAR *name,
DWORD access);
MODULE_SCOPE int TclWinSymLinkCopyDirectory(const TCHAR *LinkOriginal,
const TCHAR *LinkCopy);
Index: win/tclWinSerial.c
===================================================================
--- win/tclWinSerial.c (revision 299)
+++ win/tclWinSerial.c (working copy)
@@ -1410,23 +1410,22 @@
/*
*----------------------------------------------------------------------
*
- * TclWinSerialReopen --
+ * TclWinSerialOpen --
*
- * Reopens the serial port with the OVERLAPPED FLAG set
+ * Opens or Reopens the serial port with the OVERLAPPED FLAG set
*
* Results:
- * Returns the new handle, or INVALID_HANDLE_VALUE. Normally there
- * shouldn't be any error, because the same channel has previously been
- * succeesfully opened.
+ * Returns the new handle, or INVALID_HANDLE_VALUE.
+ * I an existing channel is specified it is closed and reopened.
*
* Side effects:
- * May close the original handle
+ * May close/reopen the original handle
*
*----------------------------------------------------------------------
*/

HANDLE
-TclWinSerialReopen(
+TclWinSerialOpen(
HANDLE handle,
const TCHAR *name,
DWORD access)
@@ -1434,17 +1433,25 @@
SerialInit();

/*
- * Multithreaded I/O needs the overlapped flag set otherwise
- * ClearCommError blocks under Windows NT/2000 until serial output is
- * finished
+ * If an open channel is specified, close it
*/

- if (CloseHandle(handle) == FALSE) {
- return INVALID_HANDLE_VALUE;
+ if ( handle != INVALID_HANDLE_VALUE ) {
+ if (CloseHandle(handle) == FALSE) {
+ return INVALID_HANDLE_VALUE;
+ }
}
+
+ /*
+ * Multithreaded I/O needs the overlapped flag set otherwise
+ * ClearCommError blocks under Windows NT/2000 until serial output is
+ * finished
+ */
+
handle = CreateFile(name, access, 0, 0, OPEN_EXISTING,
FILE_FLAG_OVERLAPPED, 0);
- return handle;
+
+ return handle;
}

/*

[Philip Hoffman]

I found that the issue was that I was not using "make install." Like I said before, I'm pretty new to all of this. Turns out that I am still dependant on the libraries provided by the Activestate binary distribution. I'll figure all that out another time.

I replaced the tcl86.dll in the Activestate distribution with the one produced with the code fix. It is working great so far both with the physical serial ports and the bluetooth ports.

However when I compile with the MSVC 2010 for whatever reason there seems to be a dependency to a dll file that MSVC provides. I'm scratching my head on that one, I'll see if I can get some other compiler to work.

[Harald Oehlmann]

Am Donnerstag, 6. Februar 2014 20:47:39 UTC+1 schrieb Philip Hoffman:
> I found that the issue was that I was not using "make install." Like I said before, I'm pretty new to all of this. Turns out that I am still dependant on the libraries provided by the Activestate binary distribution. I'll figure all that out another time.
>
>
>
> I replaced the tcl86.dll in the Activestate distribution with the one produced with the code fix. It is working great so far both with the physical serial ports and the bluetooth ports.
>

Wow ! With the upper patch or the branch or with released tcl 8.6.1 ?

> However when I compile with the MSVC 2010 for whatever reason there seems to be a dependency to a dll file that MSVC provides. I'm scratching my head on that one, I'll see if I can get some other compiler to work.

This is due to so called "DLL hell".
The only way to not get dependencies is to use MS-VC++ 6. Any newer will require on some platforms to install the free MSVC CRT package.

If you use MSVC 10, it should be:
http://www.microsoft.com/de-de/download/details.aspx?id=8328

Great,
Harald

[Philip Hoffman]

They are with the released version, specifically where the link takes me from here http://tcl.tk/software/tcltk/download.html.

Thank you for looking into it. I'll try compiling with MinGW and see if that gets around the requirement for the CRT package.

So what's the next step here to see that this makes it into the next release of 8.5 and 8.6?

[Harald Oehlmann]

Am Montag, 10. Februar 2014 17:03:11 UTC+1 schrieb Philip Hoffman:
> They are with the released version, specifically where the link takes me from here http://tcl.tk/software/tcltk/download.html.
>

So there is no need for a patch ?
Or do you mean, you take the release version and patch that one ?

> Thank you for looking into it. I'll try compiling with MinGW and see if that gets around the requirement for the CRT package.

If you have the sources, I can compile it for you with msvc6++.
Mingw should work to. I never succeeded to do that.

> So what's the next step here to see that this makes it into the next release of 8.5 and 8.6?

(1) First step is to bring branch in good state and that it works for you:

https://core.tcl.tk/tcl/info/5ef480c185

Press on "Download as zip" to get the source.

Please instruct me, if there is anything wrong with it.

(2) Review by a wizard

I would ask Alexandre Ferrieux or Andreas Kupries to review the patch.
If they give green light, I would probably ask Jan Nijtmans to merge to 8.5 or do it myself.

(3) Tcl 8.6

Next step is the integration into 8.6. I personally would ask Jan Nijtmans how to approach that, if a branch is again senseful or directly go into trunk.
Maybee first a branch, than a test and then into trunk.

Harald

[Philip Hoffman]

Harald,

Let's go for 2 and 3 since I don't fully understand all of the modifications I did make to the patch. I sent an email with the modifications. Let me know if it doesn't come through.

- Phil

[Harald Oehlmann]

Phil,

thank you for the E-Mail.

I have included the patch in fossil:
https://core.tcl.tk/tcl/info/024a523361

A compiled test version is also sent to you.

Enjoy,
Harald

[Harald Oehlmann]

Patch is in 8-5-branch and trunk now.
Thanks to everybody,
Harald