Forum Index > .CommName is no more?

By: Guest Posted on: Feb 6 2014 at 03:58:54 PM

What happened to .CommName that was in the comm32 api? Is there an alternative way to get that functionality under comm64?


By: Guest Posted on: Feb 6 2014 at 05:44:17 PM
to add more: IDE suggests getPortName(portnum), but (1) it's not advertised and (2) also while it appears to work on the machine I built it and the program crashes on another machine as it can't find:

Comm64.Comm:getPortName (int)

the com64 dll is in the same folder as the .exe, and everything else within comm64 realm works if i don't call getPortName

By: Guest Posted on: Feb 6 2014 at 05:45:55 PM
Is there a standard windows API to get the long port name? I couldn't find one searching with google.

Thank you.

By: Guest Posted on: Feb 10 2014 at 03:37:03 AM
Sounds like you built your application against version 6.4..29 (or later) of the DLL. But then placing your EXE on another machine which has an older version of the DLL.

You need to ensure you're using/deploying the same version of the DLL.

.getPortName(int) was only added in 6.4..29 or later.

By: Guest Posted on: Feb 10 2014 at 12:46:32 PM
1. No, it's the same DLL

2. Is getPortName(1) going to be in the public API - it's not advertised on the website

3. What happened to .CommName?

Thank you.

By: Ian Posted on: Feb 10 2014 at 03:36:32 PM
The Comm64 DLL is not an upgrade or updated version of sComm32.ocx
It's an entirely different project so reason for them to have the same syntax.

Would you run a test. The computer where it crashes. Would you run your application as administrator and let us know whether that makes any difference.

By: Guest Posted on: Feb 10 2014 at 06:25:16 PM
Sorry if I wasn't clear, I'm not complaining that .CommName has disappeared, I'm asking why have you remove it - i.e. trying to gain a technical understanding.

I'm trying to run the app under wine emulation on linux, and everything in your library works except I'm trying to figure out how to get the long port names working. When running SComm32.ocx's CommName it returns "" under wine. That's why I'm trying to understand why .CommName was removed in hope to gain an insight of why .CommName isn't working under wine. I hope that makes sense.

What would help me the most is if you could show me just the single line of the source code of .CommName implementation where you get the long port name from the system. Then I could investigate why is it not working under wine. I have a suspicion but w/o knowing which call is the failing one I can't report to the creators of the wine library at where there might be a problem and therefore get it fixed.

Thank you.

Thank you.

Thank you.

By: Support Posted on: Feb 11 2014 at 11:37:33 AM
CommName no more ? CommName never was. The CommName function has never existed in Comm64 so was not removed.

Comm32 is written using VisualStudio v6 using COM/Win32 API
Comm64 is written in c# 2010 targeting the .Net framework.

The componemts are not related. They don't have a single line of code in common so no attempt has been made to simulate Comm32 syntax in Comm64

Lets concentrate on the Comm64 .getPortName function. You mentioned that it works on one machine but not on the other.

You also mentioned Linux/Wine. Are both machines Linux/Wine ? Or is the working one a normal Windows machine ?

By: Guest Posted on: Feb 12 2014 at 06:41:19 PM
I will explain why I make it sound more complicated than it should be.

I have a binary of a program that was written under VB6 that uses Scomm32 API, and it works under windows, but fails under linux/wine. For that program to work it needs to detect one or more serial connections and then the rest of the program works using those connections. So on the same computer it detects the COM connections if I run the program via vmware's winxp guest, but not via linux/wine.

The creator of the program won't show me the source code, so I had to try to and reverse engineer things to try and understand why the program fails. So I went ahead and wrote a few little programs trying to guess how he may have written it. I never developed under windows or use it much and I couldn't figure out how to get VB6 studio as it is discontinued, so I figured I'll try VB.NET and that's how I ended up trying comm64. since I figured that if that fails it'd explain to me why scomm32 fails. That's the long convoluted story.

What I learned is that the following serial port detection code works under windows but not linux/wine:

For Each sp As String In My.Computer.Ports.SerialPortNames
Console.WriteLine("Port Trying " + sp)

i.e. under wine SerialPortNames returns an empty list, even though the COM ports are there and I can open and connect to them (e.g. if I just loop through a hardcoded COM1..COM16)

I also tried:

Dim ports As String() = SerialPort.GetPortNames()
' Display each port name to the console.
Dim port As String
For Each port In ports
Next port

same results.

I then tried to find a Comm64's accessor to get the port name, just to discover that there isn't one by looking at the online docs. But then IDE suggested .getPortName, which I tried to use and when I added it the program won't even start under wine/linux, with a trace that indicates that it can't find the method. Even though all other Comm64 accessors do work (I can talk to the ports if I hardcode the port number). and comm64.dll is in the same folder as the .exe.

So clearly some part of the emulation is missing in the wine implementation, and I'm trying to figure out which win API syscall is the one responsible for CommName/getPortName so that I could debug this on the linux side and get this fixed in wine. That's why I asked if you could tell me what CommName/getPortName call internally.

I hope that explains my very odd situation and the questions that stem out of it.

Thank you for bearing with me.
It works under winxp where the program was written

By: Support Posted on: Feb 13 2014 at 01:52:58 PM
Comm64 uses the .Net framework. It seems to me that wine does not fully mplement the System.Management namespace of the .Net framework.

If you could get wine updated to fully support that namespace then that still wouldn't fix the problem with the VB6 /scomm32 program because their is no similarity at all between the two.

By: Guest Posted on: Feb 13 2014 at 03:17:21 PM
From what I understand wine doesn't implement any frameworks, it emulates the windows api to the hardware, translating from linux to windows. any frameworks are installed as they are w/o any mods. The intention behind wine is to be transparent to any components running on top of windows. So it's some very low level api that's not fully implemented, and I just keep hitting the wall trying to figure out what that system call would be.

But since it seems that everybody in the windows world is so secretive about everything, it's ok, I will just find some workaround that requires no windows in first place.

Thank you for trying to help.

By: Guest Posted on: Feb 14 2014 at 02:21:58 AM
Ok. Maybe support didnt go into as much detail as you wanted. What he/she meant was that Comm64 makes calls to the .net framework and the framework, in turn, makes some call to the underlying Windows API. In the case of Wine that windows api call appears to be not fully supported. ie not fully implemented.

But you already knew that.

Now its not that Support is being secretive. Its just that they possibly don't know or care what the underlying Win API call is. The whole idea of targeting a framework such as .net framework is that a .net developer does not need to worry about the OS underneath. For example; writing for .net without worrying about the underying OS or Win API means that a correctly written .net application can be ported to other similar frameworks such as MONO without much work.

Now im not saying that Comm64 could be ported to the MONO framework. I don't know enough about it.

But read Support's post. They mentioned the SYSTEM.MANAGEMENT NAMESPACE.

Personally i think that by mentioning that, they've done 75% of the work for you. They are being more helpful than you think. Now i'll do another 10%. Write your own little .net application that makes use of that namespace and explore how that is thunked down to the windows api. If you don't know how to do that then you really do need to try or you'll never learn.

As for Windows developers being secretive. I have a question. How do linux developers make a living.? I am a linux developer. I give my linux code away for free. But i can only afford to do that because i also sell windows code that pays the bills. If i gave away my windows code i'd have to go back to flipping burgers and I'd have no time to develop any code at all.

By: Guest Posted on: Feb 14 2014 at 01:22:21 PM
Apologies if I hit some buttons there. I didn't ask to reveal all of the source code. All I was asking is to show me a *single* line of code used to retrieve the comm port name. If such to be shown, the developers of comm64 won't need to join the burger flipping crowd. And I then could continue tracing the problem down to the next level.

And thank you for suggesting to work through SYSTEM.MANAGEMENT namespace.


Reply - add comment to this topic
You may enter letters, numbers and standard punctuation only. HTML and other scripts/tags will be rejected
  Topic:- .CommName is no more?

Your Name


Forum scripts and databases - Copyright (c) 2009 - 2012