s = (PSOCKET) ExAllocatePoolWithTag(NonPagedPool, sizeof(SOCKET),
‘gaTs’);
if (!s) {
return STATUS_INSUFFICIENT_RESOURCES;
}
RtlZeroMemory(s, sizeof(SOCKET));
s->type = type;
s->address_handle = (HANDLE) *-1; *// I am not able to understand why -1
?*
return -(int)((INT_PTR)(s)); *// Is it correct to return a minus value
of a pointer for 64 bit driver ??
}
** Can any one please help to understand what is point in returning a -
‘minus’ of a pointer.
this code works for 32 bit?
** But on 64 bit it has got crashed.
** Is it wise to return a - ‘minus’ of a pointer for a 64 bit driver ?
** Or Can any one please guide me as what approach shall I take in further ?
I have listed down some of the sock library simulated functions which
accepts this socket and before using it they again put a - ‘minus’ sign.
int __cdecl bind( int socket, …)
{
…
PSOCKET s = (PSOCKET) -(INT_PTR)socket; // how significant it is
?
int __cdecl close(int socket)
{
PSOCKET s = (PSOCKET) -(INT_PTR)socket; // how significant it is ?
…
int __cdecl connect( int socket, …)
{
PSOCKET s = (PSOCKET) -(INT_PTR)socket; // how significant it is
?
…
…
…
status = tdi_open_connection_endpoint(
&dev_name,
s->stream_socket,
…
…
}
I think this code is trying to pass kernel address using signed integer and hence performing some trick on that. u can not have it in 31 bits, right.
> s->address_handle = (HANDLE) *-1; *// I am not able to understand why -1
This is the value which is return by current process handle retriving APIs.
>// Is it correct to return a minus value of a pointer for 64 bit driver ?? }
it is not returning a minus value of pointer, (assuming there is no confusion in INT_PTR), it is simply tying to return the allocated address in numeric form and later on reversing it to retrieve a pointer again.
>return -(int)((INT_PTR)(s));
In 64 bit, address will be truncated to a 32 bit signed value, which is not going to work obviously,
you better try INT_PTR in place of ints. And check why exactly your code needs such tricks to pass a address. why not use a pointer of otherwise use a UINT atleast.
One major problem with your socket library is that a ‘socket’ is being
represented as an int externally rather than a pointer compatible type,
while internally it is of course a pointer to a structure. It would be
better to convert the external representation to a type that is compatible
with 32/64 pointers, such as INT_PTR, PVOID, etc.
I have no idea what the intention is with transforming the ‘pointer to
SOCKET’ into a negative value, other than perhaps masking it and suggest
that you not do that anymore. Change the external type of a socket to an
INT_PTR, and just return the address of the internal PSOCKET from the call
to socket.
You will have to change all the callers of your socket library to use
INT_PTR to represent sockets.
Mark Roddy
On Fri, Feb 27, 2009 at 3:04 AM, Bharat Kulkarni wrote:
> > Hi All, > > I fairly new to TDI driver. > > I was trying to port a already written 32 bit driver on 64 bit for w2k3 OS. > > Current driver has functionality where it communicates with a remote > machine using socket library simulated functions with TDI. > > sock library simulation code is completely taken from linux and modified in > such a way that it will internally call the TDI functions respectively. > > the code for socket() is written like as follows, > > typedef struct _SOCKET { > int type; > BOOLEAN is_bound; > BOOLEAN is_connected; > BOOLEAN is_listening; > BOOLEAN is_shuttingdown; > BOOLEAN is_shared; > HANDLE address_handle; > PFILE_OBJECT address_file_object; > PSTREAM_SOCKET stream_socket; > struct sockaddr peer; > } SOCKET, *PSOCKET; > > int __cdecl socket( > int af, > int type, > int protocol) > { > PSOCKET s; > > if (af != AF_INET || > (type != SOCK_DGRAM && type != SOCK_STREAM) || > (type == SOCK_DGRAM && protocol != IPPROTO_UDP && protocol != 0) || > (type == SOCK_STREAM && protocol != IPPROTO_TCP && protocol != 0)) { > return STATUS_INVALID_PARAMETER; > } > > s = (PSOCKET) ExAllocatePoolWithTag(NonPagedPool, sizeof(SOCKET), > ‘gaTs’); > > if (!s) { > return STATUS_INSUFFICIENT_RESOURCES; > } > > RtlZeroMemory(s, sizeof(SOCKET)); > > s->type = type; > s->address_handle = (HANDLE) *-1; // I am not able to understand why > -1 ? > > return -(int)((INT_PTR)(s)); *// Is it correct to return a minus value > of a pointer for 64 bit driver ?? > } > > Can any one please help to understand what is point in returning a - > ‘minus’ of a pointer. > this code works for 32 bit? > > But on 64 bit it has got crashed. > > Is it wise to return a - ‘minus’ of a pointer for a 64 bit driver ? > > Or Can any one please guide me as what approach shall I take in further > ? > > I have listed down some of the sock library simulated functions which > accepts this socket and before using it they again put a - ‘minus’ sign. > > int__cdecl bind( int socket, …) > { > … > PSOCKET s = (PSOCKET) -(INT_PTR)socket; // how significant it > is ? > > int __cdecl close(int socket) > { > PSOCKET s = (PSOCKET) -(INT_PTR)socket; // how significant it is ? > … > > int__cdecl connect( int socket, …) > { > PSOCKET s = (PSOCKET) -(INT_PTR)socket; // how significant it > is ? > … > … > … > status = tdi_open_connection_endpoint( > &dev_name, > s->stream_socket, > … > … > } > > Thanks, > Bharat. > > — NTDEV is sponsored by OSR For our schedule of WDF, WDM, debugging and > other seminars visit: http://www.osr.com/seminars To unsubscribe, visit > the List Server section of OSR Online at > http://www.osronline.com/page.cfm?name=ListServer
Quite possibly because (SOCKET)(-1) is the value of an ‘invalid’ (no) socket
but (SOCKET)(0) is actually legal in the semantics of sockets? Also
because kernel mode addresses are always ‘negative’ when considered as a
signed 2s compliment integer value. It looks like a poorly explained way to
maintain the value semantics whereby the invalid (or no) pointer value NULL
is transformed into the invalid (or no) SOCKET value through a symmetric
operation (instead of a comparison) and where ‘valid’ values are positive
and negative values are ‘invalid’.
But I am just guessing.
If the external client of this code gets its definition of SOCKET from a
single header file, that would be very helpful to ‘fixing’ this. A typedef
for SOCKET ought to either by an handle style (opaque pointer) or at least a
INT_PTR.
Dave Cattley
Consulting Engineer
Systems Software Development
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Mark Roddy
Sent: Friday, February 27, 2009 8:45 AM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] Is it wise to return -(int)((INT_PTR)s); in 64 bit
driver ?
One major problem with your socket library is that a ‘socket’ is being
represented as an int externally rather than a pointer compatible type,
while internally it is of course a pointer to a structure. It would be
better to convert the external representation to a type that is compatible
with 32/64 pointers, such as INT_PTR, PVOID, etc.
I have no idea what the intention is with transforming the ‘pointer to
SOCKET’ into a negative value, other than perhaps masking it and suggest
that you not do that anymore. Change the external type of a socket to an
INT_PTR, and just return the address of the internal PSOCKET from the call
to socket.
You will have to change all the callers of your socket library to use
INT_PTR to represent sockets.
Mark Roddy
On Fri, Feb 27, 2009 at 3:04 AM, Bharat Kulkarni wrote:
Hi All,
I fairly new to TDI driver.
I was trying to port a already written 32 bit driver on 64 bit for w2k3 OS.
Current driver has functionality where it communicates with a remote machine using socket library simulated functions with TDI.
sock library simulation code is completely taken from linux and modified in such a way that it will internally call the TDI functions respectively.
It looks like the external mapping is just “int to PSOCKET” which is just
not 32/64 portable.
The failure case could still be dealt with as (INT_PTR) -1, as in the
INVALID_HANDLE usage for HANDLE values.
The zero case would be fine, it just wouldn’t happen.
The other alternative is to provide an internal mapping from int to PSOCKET
through an internal table. That would keep the client code base unchanged.
None of this explains the code segment, which was returning the PSOCKET
value converted to an int and multiplied by (-1) for the success case.
Perhaps the OP neglected to include any code that deconverted the negated
values internally?
Why this all blew up on 64 bits is obvious, how it managed to work on 32
bits is a bit of a mystery.
Mark Roddy
On Fri, Feb 27, 2009 at 9:23 AM, David R. Cattley wrote:
>
> > Quite possibly because (SOCKET)(-1) is the value of an ‘invalid’ (no) > socket > but (SOCKET)(0) is actually legal in the semantics of sockets? Also > because kernel mode addresses are always ‘negative’ when considered as a > signed 2s compliment integer value. It looks like a poorly explained way to > maintain the value semantics whereby the invalid (or no) pointer value NULL > is transformed into the invalid (or no) SOCKET value through a symmetric > operation (instead of a comparison) and where ‘valid’ values are positive > and negative values are ‘invalid’. > > But I am just guessing. > > If the external client of this code gets its definition of SOCKET from a > single header file, that would be very helpful to ‘fixing’ this. A > typedef > for SOCKET ought to either by an handle style (opaque pointer) or at least > a > INT_PTR. > > Dave Cattley > Consulting Engineer > Systems Software Development > > From: xxxxx@lists.osr.com > [mailto:xxxxx@lists.osr.com] On Behalf Of Mark Roddy > Sent: Friday, February 27, 2009 8:45 AM > To: Windows System Software Devs Interest List > Subject: Re: [ntdev] Is it wise to return -(int)((INT_PTR)s); in 64 bit > driver ? > > One major problem with your socket library is that a ‘socket’ is being > represented as an int externally rather than a pointer compatible type, > while internally it is of course a pointer to a structure. It would be > better to convert the external representation to a type that is compatible > with 32/64 pointers, such as INT_PTR, PVOID, etc. > > I have no idea what the intention is with transforming the ‘pointer to > SOCKET’ into a negative value, other than perhaps masking it and suggest > that you not do that anymore. Change the external type of a socket to an > INT_PTR, and just return the address of the internal PSOCKET from the call > to socket. > > You will have to change all the callers of your socket library to use > INT_PTR to represent sockets. > > Mark Roddy > > On Fri, Feb 27, 2009 at 3:04 AM, Bharat Kulkarni > wrote: > > Hi All, > > I fairly new to TDI driver. > > I was trying to port a already written 32 bit driver on 64 bit for w2k3 OS. > > Current driver has functionality where it communicates with a remote > machine > using socket library simulated functions with TDI. > > sock library simulation code is completely taken from linux and modified in > such a way that it will internally call the TDI functions respectively. > > the code for socket() is written like as follows, > > typedef struct _SOCKET { > int type; > BOOLEAN is_bound; > BOOLEAN is_connected; > BOOLEAN is_listening; > BOOLEAN is_shuttingdown; > BOOLEAN is_shared; > HANDLE address_handle; > PFILE_OBJECT address_file_object; > PSTREAM_SOCKET stream_socket; > struct sockaddr peer; > } SOCKET, *PSOCKET; > > int __cdecl socket( > int af, > int type, > int protocol) > { > PSOCKET s; > > if (af != AF_INET || > (type != SOCK_DGRAM && type != SOCK_STREAM) || > (type == SOCK_DGRAM && protocol != IPPROTO_UDP && protocol != 0) || > (type == SOCK_STREAM && protocol != IPPROTO_TCP && protocol != 0)) { > return STATUS_INVALID_PARAMETER; > } > > s = (PSOCKET) ExAllocatePoolWithTag(NonPagedPool, sizeof(SOCKET), > ‘gaTs’); > > if (!s) { > return STATUS_INSUFFICIENT_RESOURCES; > } > > RtlZeroMemory(s, sizeof(SOCKET)); > > s->type = type; > s->address_handle = (HANDLE) -1; // I am not able to understand why -1 > ? > > return -(int)((INT_PTR)(s)); // Is it correct to return a minus value > of > a pointer for 64 bit driver ?? > } > > Can any one please help to understand what is point in returning a - > ‘minus’ of a pointer. > this code works for 32 bit? > > But on 64 bit it has got crashed. > > Is it wise to return a - ‘minus’ of a pointer for a 64 bit driver ? > > Or Can any one please guide me as what approach shall I take in further > ? > > > I have listed down some of the sock library simulated functions which > accepts this socket and before using it they again put a - ‘minus’ sign. > > int__cdecl bind( int socket, …) > { > … > PSOCKET s = (PSOCKET) -(INT_PTR)socket; // how significant it is > ? > > int __cdecl close(int socket) > { > PSOCKET s = (PSOCKET) -(INT_PTR)socket; // how significant it is ? > … > > int__cdecl connect( int socket, …) > { > PSOCKET s = (PSOCKET) -(INT_PTR)socket; // how significant it is > ? > … > … > … > status = tdi_open_connection_endpoint( > &dev_name, > s->stream_socket, > … > … > } > > Thanks, > Bharat. > > — NTDEV is sponsored by OSR For our schedule of WDF, WDM, debugging and > other seminars visit: http://www.osr.com/seminars To unsubscribe, visit > the > List Server section of OSR Online at > http://www.osronline.com/page.cfm?name=ListServer > > — NTDEV is sponsored by OSR For our schedule of WDF, WDM, debugging and > other seminars visit: http://www.osr.com/seminars To unsubscribe, visit > the > List Server section of OSR Online at > http://www.osronline.com/page.cfm?name=ListServer > > > — > NTDEV is sponsored by OSR > > For our schedule of WDF, WDM, debugging and other seminars visit: > http://www.osr.com/seminars > > To unsubscribe, visit the List Server section of OSR Online at > http://www.osronline.com/page.cfm?name=ListServer >
It is common and accepted practice in sys/socket.h based code to test a
socket descriptor ?value? for its sign.
SOCKET sd;
if ((sd = socket(?)) < 0)
{
// bummer, it failed. [ed: of course, being *nix code, there
would not be a comment?]
}
So it is actually the value range semantics that become important.
The ?negation? is maintaining the value semantics. One?s compliment
seems better to me and I apologize for my previous inaccuracy regarding NULL
-> (-1). A one?s compliment operation does that mapping automatically of
course and I was thinking of that. The two?s compliment negation does *not*
change the value of zero and thus the exception code in the OP?s post for
NULL.
Also, the sys/socket.h client code expects that when an operation returning
a SOCKET fails, the negative value is an error value indicating the reason.
So this code also implicitly relies on the fact that STATUS_XXX values for
error conditions are ‘negative’ and will sign-extend. So actually, the
error returns are also busted since I do not think they will sign-extend.
-dave
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Mark Roddy
Sent: Friday, February 27, 2009 9:34 AM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] Is it wise to return -(int)((INT_PTR)s); in 64 bit
driver ?
It looks like the external mapping is just “int to PSOCKET” which is just
not 32/64 portable.
The failure case could still be dealt with as (INT_PTR) -1, as in the
INVALID_HANDLE usage for HANDLE values.
The zero case would be fine, it just wouldn’t happen.
The other alternative is to provide an internal mapping from int to PSOCKET
through an internal table. That would keep the client code base unchanged.
None of this explains the code segment, which was returning the PSOCKET
value converted to an int and multiplied by (-1) for the success case.
Perhaps the OP neglected to include any code that deconverted the negated
values internally?
Why this all blew up on 64 bits is obvious, how it managed to work on 32
bits is a bit of a mystery.
Mark Roddy
On Fri, Feb 27, 2009 at 9:23 AM, David R. Cattley wrote:
Quite possibly because (SOCKET)(-1) is the value of an ‘invalid’ (no) socket but (SOCKET)(0) is actually legal in the semantics of sockets? ? ?Also because kernel mode addresses are always ‘negative’ when considered as a signed 2s compliment integer value. It looks like a poorly explained way to maintain the value semantics whereby the invalid (or no) pointer value NULL is transformed into the invalid (or no) SOCKET value through a symmetric operation (instead of a comparison) and where ‘valid’ values are positive and negative values are ‘invalid’.
But I am just guessing.
If the external client of this code gets its definition of SOCKET from a single header file, that would be very helpful to ‘fixing’ this. ? A typedef for SOCKET ought to either by an handle style (opaque pointer) or at least a INT_PTR.
Dave Cattley Consulting Engineer Systems Software Development
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Mark Roddy Sent: Friday, February 27, 2009 8:45 AM To: Windows System Software Devs Interest List Subject: Re: [ntdev] Is it wise to return -(int)((INT_PTR)s); in 64 bit driver ?
One major problem with your socket library is that a ‘socket’ is being represented as an int externally rather than a pointer compatible type, while internally it is of course a pointer to a structure. It would be better to convert the external representation to a type that is compatible with 32/64 pointers, such as INT_PTR, PVOID, etc.
I have no idea what the intention is with transforming the ‘pointer to SOCKET’ into a negative value, other than perhaps masking it and suggest that you not do that anymore. Change the external type of a socket to an INT_PTR, and just return the address of the internal PSOCKET from the call to socket.
You will have to change all the callers of your socket library to use INT_PTR to represent sockets.
Mark Roddy
On Fri, Feb 27, 2009 at 3:04 AM, Bharat Kulkarni wrote:
Hi All,
I fairly new to TDI driver.
I was trying to port a already written 32 bit driver on 64 bit for w2k3 OS.
Current driver has functionality where it communicates with a remote machine using socket library simulated functions with TDI.
sock library simulation code is completely taken from linux and modified in such a way that it will internally call the TDI functions respectively.
Why this all blew up on 64 bits is obvious, how it managed to work on 32 bits is a bit of a mystery.
Probably because the client does not actually see into the PSOCKET structure
only the library does. And the library does this funky (equivalent of a
cast) operation at each API ingress point and the reverse operation at ever
place it returns a socket value.
Why do some developers create obtuse and confusing solutions to a problem with a simple goal. At least have the solution be clear about what the goal is and not just be ‘implementation’. Can I buy you a couple of macros?
With those three macros, you may still have had problems on 64-bit but at least someone reading the frigg’n code would have had a clue what the <… inane expression …> was trying to do. And when they fixed it, they would not need to hit 47 API entrypoints with the same search & replace.
Where have the software engineers gone…
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Mark Roddy
Sent: Friday, February 27, 2009 9:34 AM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] Is it wise to return -(int)((INT_PTR)s); in 64 bit
driver ?
It looks like the external mapping is just “int to PSOCKET” which is just
not 32/64 portable.
The failure case could still be dealt with as (INT_PTR) -1, as in the
INVALID_HANDLE usage for HANDLE values.
The zero case would be fine, it just wouldn’t happen.
The other alternative is to provide an internal mapping from int to PSOCKET
through an internal table. That would keep the client code base unchanged.
None of this explains the code segment, which was returning the PSOCKET
value converted to an int and multiplied by (-1) for the success case.
Perhaps the OP neglected to include any code that deconverted the negated
values internally?
Why this all blew up on 64 bits is obvious, how it managed to work on 32
bits is a bit of a mystery.
Mark Roddy
On Fri, Feb 27, 2009 at 9:23 AM, David R. Cattley wrote:
Quite possibly because (SOCKET)(-1) is the value of an ‘invalid’ (no) socket but (SOCKET)(0) is actually legal in the semantics of sockets? ? ?Also because kernel mode addresses are always ‘negative’ when considered as a signed 2s compliment integer value. It looks like a poorly explained way to maintain the value semantics whereby the invalid (or no) pointer value NULL is transformed into the invalid (or no) SOCKET value through a symmetric operation (instead of a comparison) and where ‘valid’ values are positive and negative values are ‘invalid’.
But I am just guessing.
If the external client of this code gets its definition of SOCKET from a single header file, that would be very helpful to ‘fixing’ this. ? A typedef for SOCKET ought to either by an handle style (opaque pointer) or at least a INT_PTR.
Dave Cattley Consulting Engineer Systems Software Development
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Mark Roddy Sent: Friday, February 27, 2009 8:45 AM To: Windows System Software Devs Interest List Subject: Re: [ntdev] Is it wise to return -(int)((INT_PTR)s); in 64 bit driver ?
One major problem with your socket library is that a ‘socket’ is being represented as an int externally rather than a pointer compatible type, while internally it is of course a pointer to a structure. It would be better to convert the external representation to a type that is compatible with 32/64 pointers, such as INT_PTR, PVOID, etc.
I have no idea what the intention is with transforming the ‘pointer to SOCKET’ into a negative value, other than perhaps masking it and suggest that you not do that anymore. Change the external type of a socket to an INT_PTR, and just return the address of the internal PSOCKET from the call to socket.
You will have to change all the callers of your socket library to use INT_PTR to represent sockets.
Mark Roddy
On Fri, Feb 27, 2009 at 3:04 AM, Bharat Kulkarni wrote:
Hi All,
I fairly new to TDI driver.
I was trying to port a already written 32 bit driver on 64 bit for w2k3 OS.
Current driver has functionality where it communicates with a remote machine using socket library simulated functions with TDI.
sock library simulation code is completely taken from linux and modified in such a way that it will internally call the TDI functions respectively.
And how about everywhere your library *knows* an error return is occurring,
and ASSERT(socketval < 0) and everywhere it *knows* it is returning a socket
an ASSERT( socketval >= 0)
…
But Mark’s comment about implementing an 32-bit handle (index) table is a
‘really good idea’ because trusting the client to not do things like close a
socket and then try to use it again in another call is perhaps too
dangerous. I would consider using he handle table even for 32-bit or at
least provide some checked-build validation of the SOCKET value other than
let the system bugcheck because it might *not* bugcheck because the freed
PSOCKET might just have come back as a new PSOCKET.
Ok, I will shut up now.
-Dave
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of David R. Cattley
Sent: Friday, February 27, 2009 10:12 AM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Is it wise to return -(int)((INT_PTR)s); in 64 bit
driver ?
Why this all blew up on 64 bits is obvious, how it managed to work on 32 bits is a bit of a mystery.
Probably because the client does not actually see into the PSOCKET structure
only the library does. And the library does this funky (equivalent of a
cast) operation at each API ingress point and the reverse operation at ever
place it returns a socket value.
Why do some developers create obtuse and confusing solutions to a problem with a simple goal. At least have the solution be clear about what the goal is and not just be ‘implementation’. Can I buy you a couple of macros?
With those three macros, you may still have had problems on 64-bit but at least someone reading the frigg’n code would have had a clue what the <… inane expression …> was trying to do. And when they fixed it, they would not need to hit 47 API entrypoints with the same search & replace.
Where have the software engineers gone…
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Mark Roddy
Sent: Friday, February 27, 2009 9:34 AM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] Is it wise to return -(int)((INT_PTR)s); in 64 bit
driver ?
It looks like the external mapping is just “int to PSOCKET” which is just
not 32/64 portable.
The failure case could still be dealt with as (INT_PTR) -1, as in the
INVALID_HANDLE usage for HANDLE values.
The zero case would be fine, it just wouldn’t happen.
The other alternative is to provide an internal mapping from int to PSOCKET
through an internal table. That would keep the client code base unchanged.
None of this explains the code segment, which was returning the PSOCKET
value converted to an int and multiplied by (-1) for the success case.
Perhaps the OP neglected to include any code that deconverted the negated
values internally?
Why this all blew up on 64 bits is obvious, how it managed to work on 32
bits is a bit of a mystery.
Mark Roddy
On Fri, Feb 27, 2009 at 9:23 AM, David R. Cattley wrote:
Quite possibly because (SOCKET)(-1) is the value of an ‘invalid’ (no) socket but (SOCKET)(0) is actually legal in the semantics of sockets? ? ?Also because kernel mode addresses are always ‘negative’ when considered as a signed 2s compliment integer value. It looks like a poorly explained way to maintain the value semantics whereby the invalid (or no) pointer value NULL is transformed into the invalid (or no) SOCKET value through a symmetric operation (instead of a comparison) and where ‘valid’ values are positive and negative values are ‘invalid’.
But I am just guessing.
If the external client of this code gets its definition of SOCKET from a single header file, that would be very helpful to ‘fixing’ this. ? A typedef for SOCKET ought to either by an handle style (opaque pointer) or at least a INT_PTR.
Dave Cattley Consulting Engineer Systems Software Development
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Mark Roddy Sent: Friday, February 27, 2009 8:45 AM To: Windows System Software Devs Interest List Subject: Re: [ntdev] Is it wise to return -(int)((INT_PTR)s); in 64 bit driver ?
One major problem with your socket library is that a ‘socket’ is being represented as an int externally rather than a pointer compatible type, while internally it is of course a pointer to a structure. It would be better to convert the external representation to a type that is compatible with 32/64 pointers, such as INT_PTR, PVOID, etc.
I have no idea what the intention is with transforming the ‘pointer to SOCKET’ into a negative value, other than perhaps masking it and suggest that you not do that anymore. Change the external type of a socket to an INT_PTR, and just return the address of the internal PSOCKET from the call to socket.
You will have to change all the callers of your socket library to use INT_PTR to represent sockets.
Mark Roddy
On Fri, Feb 27, 2009 at 3:04 AM, Bharat Kulkarni wrote:
Hi All,
I fairly new to TDI driver.
I was trying to port a already written 32 bit driver on 64 bit for w2k3 OS.
Current driver has functionality where it communicates with a remote machine using socket library simulated functions with TDI.
sock library simulation code is completely taken from linux and modified in such a way that it will internally call the TDI functions respectively.
In 64bit Linux, int is also 64bit, in Win64 it is 32bit. Use INT_PTR instead.
Also be sure that you have properly developed a socket wrapper around TDI. Linux is a different OS, and I suspect that nothing can be borrowed from it except the socket()/bind()/connect() function prototypes.
Note that you need to implement:
listen backlog
SO_SNDBUF
SO_RCVBUF
SO_LINGER
in your code.
Also note that async (completion-routine-based) and MDL-based replacements for accept()/send()/rec () are very good idea in the kernel.