📄 wpw_wapi_net_95.html
字号:
<HTML>
<HR><A NAME=WINAPI_NET_NUMBER>
Return to <a href="wpw_wapi_index.html#TOC">Table of Contents for this chapter</a><br>
<H4>Subject: Getting Network Number</H4><PRE>
hsc@eng.cam.ac.uk (Hiang-Swee Chiang) wrote:
>Hello,
>I know that each ethernet card in the world has a unique number (network
>address for LAN packet and I also know MIDL compiler for RPC used it for
>generating UUID).
>The question is how can I get it in my own program? I am using VC++2.0 on NT.
There's also a MicroSoft sample program "MACADDR", which can get you the ethernet
address, or serve as a guide for developing your own function, etc.
MACADDR does an DeviceIoControl() with IOCTL_NDIS_QUERY_GLOBAL_STATS
to your network driver to retrieve the associated MAC address. My recollection is
that you might have to load the DDK to compile and link this program.
I really don't remember where I found the sources, as just I've searched MSDN,
the 3.5 SDK, 3.5 DDK and the ftp.microsoft.com software library
for the original sources, but can't find 'em. Anyone else happen to remember?
Mike Dailey
mdailey@an.hp.com
<HR>
In article <3rr2qc$fnf@bbs.pnl.gov>
ke_piatt@pnl.gov (Kevin E Piatt) wrote:
> hsc@eng.cam.ac.uk (Hiang-Swee Chiang) wrote:
>
>>Hello,
>
>>I know that each ethernet card in the world has a unique number (network
>>address for LAN packet and I also know MIDL compiler for RPC used it for
>>generating UUID).
>
>>The question is how can I get it in my own program? I am using VC++2.0 on NT.
>
>>Any help is very much appreciated.
>
>>Regards,
>>Swee
>
> There is probably a better way, but I do a NetBIOS Adapter Status and
> use the permanent_node name, (which is the ethernet address). I first
> enumerate LANA's and use the first one (which covers most
> configurations).
Possibly the cannonical way is (from the DDK Copyright Microsoft):
OidCode = OID_802_3_CURRENT_ADDRESS;
if (DeviceIoControl(
hMAC,
IOCTL_NDIS_QUERY_GLOBAL_STATS,
&OidCode,
sizeof(OidCode),
OidData,
sizeof(OidData),
&ReturnedCount,
NULL
))
{
if (ReturnedCount == 6)
{
printf(
"Mac address = %02.2X-%02.2X-%02.2X-%02.2X-%02.2X-%02.2X\n",
OidData[0], OidData[1], OidData[2], OidData[3],
OidData[4], OidData[5], OidData[6], OidData[7]
);
}
This is from the sample "MACADDR".
You'll need the DDK headers to use this (the the IOCTL code definitions).
<HR>
In article <3rs0kl$r1e@hpaneqb4.an.hp.com>
mdailey@an.hp.com wrote:
> I really don't remember where I found the sources, as just I've searched MSDN,
> the 3.5 SDK, 3.5 DDK and the ftp.microsoft.com software library
> for the original sources, but can't find 'em. Anyone else happen to remember?
They're in the "hidden" directory off the CD root : \Q_A\samples\DDK\...
There's more useful stuff in that directory than the rest of the DDK !
(There's a similarly named, and useful, directory on the SDK CD).
</PRE>
<HR><A NAME=WINAPI_CPP_WINSOCK_WRAPPER>
Return to <a href="wpw_wapi_index.html#TOC">Table of Contents for this chapter</a><br>
<H4>Subject: C++ WinSock Wrapper</H4><PRE>
In article <3s99r0$jl5@newsbf02.news.aol.com>, CicoM <cicom@aol.com> wrote:
>Are there any C++ Winsock wrappers out there, and how compatible are
>the windows socket library calls to the UNIX ones?
>I'm relatively new to sockets, so please feel free to info-dump on me...
MFC provides a winsock wrapper which seems to be pretty solid. Although,
I just recently ported a socket based unix program over to a 16 bit
windows environment and it translated almost identically from the unix
BSD code. The only thing I had to do was rearrange my send/recv logic
and use the WSAAsyncSelect code. It worked out much better under WFW
3.1 by using the asynchronous model.
</PRE>
<HR><A NAME=WINAPI_NET_MFC_ASync>
Return to <a href="wpw_wapi_index.html#TOC">Table of Contents for this chapter</a><br>
<H4>Subject: MFC ASync Socket</H4><PRE>
Does anyone have any experiences to share concerning the new TCP-IP
interfacing classes included with the latest release of MFC?
I have had some success and some failures, but nothing that other's could gain
any significant insites from (yet).
In particular, I am interested in the proper setup and tear down of a
CAsyncSocket, and the connection and disconnect process. The sending and
receiving is pretty simple. I would prefer not to have to pick apart CSocket
source code to obtain this sort of information.
My current derived CAsyncSocket object can establish a connection get and send
data, but it can only do it once! After the application is closed no further
connections can be made using that socket because it is already in use =( I
would have thought the destructor would take care of everything for me, but I
must not be paying attention to what actually is going on.
Thanks in advance for any comments,
atl
</PRE>
<HR><A NAME=WINAPI_NET_WinSock_PPP>
Return to <a href="wpw_wapi_index.html#TOC">Table of Contents for this chapter</a><br>
<H4>Subject: Use PPP and Network together</H4><PRE>
This may be more of a windows programming program. My pc is on two
different nets at work -- a tcpip LAN (not on the internet) using
ftp-pctcp's winsock.dll, and ocassionally dial-up PPP using Trumpet. I
have to exit from windows and rename my winsock.dll to switch from one
winsock to another.
My question is this. Say I rename my trumpet winsock.dll to wintrmp.dll,
then go in with a sector editor and change all occurances of winsock.dll
to wintrmp.dll. Then I make exact duplicates of my winapps (take wftp
for example), including supporting files into seporate directories, and
edit the executables/dlls with a sector editor replacing all occurances
of winsock.dll to wintrmp.dll.
What a hack.. Anyway, does anyone know if this would work? I'm going to
attempt it anyway, but I'm just curious...
Regards,
John
pepper@callnet.com
<HR>
In article: <3s9pl1$ast@kiwi.futuris.net> pepper@callnet.com (John Martin) writes:
> This may be more of a windows programming program. My pc is on two
> different nets at work -- a tcpip LAN (not on the internet) using
> ftp-pctcp's winsock.dll, and occasionally dial-up PPP using Trumpet. I
> have to exit from windows and rename my winsock.dll to switch from one
> winsock to another.
It all depends on whether there are any programs running *all the time* that
have hooked into one WinSock.DLL or the other. In my case, I have a similar
setup to you - a TCP/IP LAN and a PPP connection. What I did was to have a
second set of Icons defined, whose working directory points to one directory
or another with the appropriate WinSock.DLL in. For example, I have one FTP
icon that 'runs' in the Trumpet Directory, so it picks up the Trumpet one (and
establishes the PPP connection etc), and I have another FTP icon that 'runs'
in the other place, to pickup the LAN copy of WinSock.DLL. When I exit the
last program to use one or the other WinSock.DLL, the DLL is unloaded by
Windows. So - admittedly, I don't get to do both PPP and LAN at the same
time, but I don't have to re-start Windows to do it.
> [binary editing snipped]
> What a hack.. Anyway, does anyone know if this would work? I'm going to
> attempt it anyway, but I'm just curious...
It might work !
--
Richard Dickins
<HR>
Richard Dickins <Rad@specview.demon.co.uk> wrote:
>In article: <3s9pl1$ast@kiwi.futuris.net> pepper@callnet.com (John Martin) writes:
>> This may be more of a windows programming program. My pc is on two
>> different nets at work -- a tcpip LAN (not on the internet) using
>> ftp-pctcp's winsock.dll, and occasionally dial-up PPP using Trumpet. I
>> have to exit from windows and rename my winsock.dll to switch from one
>> winsock to another.
>
>It all depends on whether there are any programs running *all the time* that
>have hooked into one WinSock.DLL or the other. In my case, I have a similar
>setup to you - a TCP/IP LAN and a PPP connection. What I did was to have a
>second set of Icons defined, whose working directory points to one directory
>or another with the appropriate WinSock.DLL in. For example, I have one FTP
>icon that 'runs' in the Trumpet Directory, so it picks up the Trumpet one (and
>establishes the PPP connection etc), and I have another FTP icon that 'runs'
>in the other place, to pickup the LAN copy of WinSock.DLL. When I exit the
>last program to use one or the other WinSock.DLL, the DLL is unloaded by
>Windows. So - admittedly, I don't get to do both PPP and LAN at the same
>time, but I don't have to re-start Windows to do it.
>
>> [binary editing snipped]
>> What a hack.. Anyway, does anyone know if this would work? I'm going to
>> attempt it anyway, but I'm just curious...
>
>It might work !
>
>--
>Richard Dickins
>
Ah, a great idea! All along I was assuming that once a dll loaded, a
reference to it stayed in memory, even if it was done being used and had
been unloaded from memory. Humm.. Doing the working directory way will take
care of 90% of my problems...
Thanks for the idea!
</PRE>
<HR><A NAME=WINAPI_NET_SYNC>
Return to <a href="wpw_wapi_index.html#TOC">Table of Contents for this chapter</a><br>
<H4>Subject: Use Synchronuos Socket on WinSock</H4><PRE>
In article <3trqdm$3j6@pa1.interserve.com>,
Mark H. Zellers <mzellers@Fusion.Com> wrote:
>I am working with several clients who share a common problem. They both implement
>different APIs via a shared library which optionaly exhibits synchronous
>(blocking) behaviour.
>
>I know that the WinSock spec strongly frowns on using the synchronous interfaces,
>but there are exisiting applications that people use that for reasons of source
>code compatibility depend on those interfaces.
>
>The problem that arises is that in Windows it is possible for the application
>to be re-entered in unexpected ways. Because of the differences between
>Windows and Unix implementations of sockets, these applications are quite
>suprised when they are told that the application already has a synchronous
>call in progress.
>
>The only way I have found to attempt to circumvent these problems is to disable
>input from all of the application's windows using EnableWindow during the
>durration of the synchronous call. Other attempts to implement such behaviour
>run into problems. For example, a PeekMessage loop that only looks at a
>hidden window runs into problems in that it can end up jamming Window's
>single event queue.
>
>Has anyone else explored this territory? I can't beleive I'm the first to
>run into it.
>
>Mark Z.
>
>
>
Well under multithreaded OS systems like win95, winnt, you can keep the
sockets in their default blocking mode and create threads to handle
each connection. I wrote a simple multithreaded client/server system the
other day so if you have questions send me email.
-Aaron
</PRE>
</HTML>
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -