WinNet change in CPC 1.7 rc5

Post Reply
User avatar
Josef Templ
Posts: 2047
Joined: Tue Sep 17, 2013 6:50 am

WinNet change in CPC 1.7 rc5

Post by Josef Templ »

I would like to discuss the change in WinNet in CPC 1.7 rc5 (change list number 67).
The change affects the field h_addr_list in the record type hostent.

Code: Select all

BB1.6
   h_addr_list*: POINTER TO (*?*) ARRAY [untagged] OF POINTER TO ARRAY [untagged] OF in_addr;
   where in_addr is an IPv4 address consisting of 4 bytes.

CPC 1.7 rc5
   h_addr_list*: POINTER TO (*?*) ARRAY [untagged] OF WinApi.PtrSTR;
   where TYPE WinApi.PtrSTR = POINTER TO ARRAY [untagged] OF SHORTCHAR;
According to msdn it is: char FAR FAR **h_addr_list;
In reality, however, it is also in_addr FAR FAR **h_addr_list;
I am not sure if an IPv4 address is a zero terminated string or simply a char[4],
so WinApi.PtrSTR may be misleading.
As far as I see it was correct in BB1.6 and it is simpler to use in CommTCP.
The change description mentions a module CommTCPAsync which I cannot find.

Is there any technical problem solved with the change or is it purely syntactical?
Can anybody look into this before we create an issue for changing this?

- Josef
Zinn
Posts: 476
Joined: Tue Mar 25, 2014 5:56 pm
Location: Frankfurt am Main
Contact:

Re: WinNet change in CPC 1.7 rc5

Post by Zinn »

Dear Josef.
I don’t know the answer of your questions. But I know that this topic is important and should be solved before the release of 1.7.

There are the module CommTCP exist inside BlackBox and the module CommTCPAsync downloadable from CPC.

After download and install CommTCPAsync in BlackBox 1.6 the module CommTCP is not compile able anymore because the module WinNet was changed with this package.

My aim is to get both Comm modules useable and delete WinNet in the save set.
Maybe we should insert a 0X for safety use.
- Helmut
User avatar
Josef Templ
Posts: 2047
Joined: Tue Sep 17, 2013 6:50 am

Re: WinNet change in CPC 1.7 rc5

Post by Josef Templ »

Helmut, why don't you fix CommTCPAsync?
It is trivial to fix (use the same code fragment as in CommTCP) and it
gets even simpler when it uses the unchanged WinNet.

I have never experienced long delays in setting up a connection with CommTCP, by the way.
It returns a stream long before the connection is established, so it does not
block in the way described in CommTCAsync. May be this has been changed
in later versions of CommTCP or with later versions of Windows.

- Josef
Post Reply