[lnkForumImage]
TotalShareware - Download Free Software

Confronta i prezzi di migliaia di prodotti.
Asp Forum
 Home | Login | Register | Search 


 

Forums >

microsoft.public.dotnet.framework.odbcnet

Help!!! Declare a varied-length array of structures and the use of marshalling?

peary su

4/6/2007 8:26:00 AM

Hi, everyone,

I'm writing a program to discover wireless network
using Windows Native Wifi API & VB.net.
I have to declare the windows API in my VB.net program.
The original windows declaration is as below.

The problem is in "struct _WLAN_AVAILABLE_NETWORK_LIST",
it declared "WLAN_AVAILABLE_NETWORK Network[1];".
I think which means a Network[] array of struct WLAN_AVAILABLE_NETWORK.
But how about the size of the Network[] array?
Is it "1" or more? what does "1" mean?
If I give it the size of 1, then I can get the first network back,
but if I give it more than 1, for example, 10,
then I got an error of "AccessViolationException".

The full message is "Service cannot be started.
System.AccessViolationException:
Attempted to read or write protected memory.
This is often an indication that other memory is corrupt."

Actually, the size of the Network[] array is decided by
dwNumberOfItems at run time, which means the size of the
Network[] array is varied-length not fixed, and in most situations
, the size should be more than 1.

I've searched the solution on the internet, and found some similar
situations.
They said we should use IntPtr to get the address of the structure array
and
then use Marshal class(Marshal.copy(), Marshal.PtrToStructure()....) to
get the array,
instead of declared it as a structure array, but they didn't post a
sample Marshalling code.

I've tried to code, but still got "AccessViolationException" at
Marshalling.
Anyone knows how to solve the problem?
Could you write a sample code for me in VB.net or C# without unsafe
code?

Thanks so much. I appreciate your help.

Windows Native Wifi declarations:
'-----function-----
DWORD WINAPI WlanGetAvailableNetworkList(
HANDLE hClientHandle,
const GUID* pInterfaceGuid,
DWORD dwFlags,
PVOID pReserved,
PWLAN_AVAILABLE_NETWORK_LIST* ppAvailableNetworkList
);

'-----structure-----
typedef struct _WLAN_AVAILABLE_NETWORK_LIST {
DWORD dwNumberOfItems; '===>the actual size of array
DWORD dwIndex;
WLAN_AVAILABLE_NETWORK Network[1]; '===>how to declare the array?
should I give it fixed size of 1 or change it to an IntPtr
} WLAN_AVAILABLE_NETWORK_LIST, *PWLAN_AVAILABLE_NETWORK_LIST;

typedef struct _WLAN_AVAILABLE_NETWORK {
WCHAR strProfileName[256];
DOT11_SSID dot11Ssid;
DOT11_BSS_TYPE dot11BssType;
ULONG uNumberOfBssids;
BOOL bNetworkConnectable;
WLAN_REASON_CODE wlanNotConnectableReason;
ULONG uNumberOfPhyTypes;
DOT11_PHY_TYPE dot11PhyTypes[8];
BOOL bMorePhyTypes;
WLAN_SIGNAL_QUALITY wlanSignalQuality;
BOOL bSecurityEnabled;
DOT11_AUTH_ALGORITHM dot11DefaultAuthAlgorithm;
DOT11_CIPHER_ALGORITHM dot11DefaultCipherAlgorithm;
DWORD dwFlags;
DWORD dwReserved;
} WLAN_AVAILABLE_NETWORK, *PWLAN_AVAILABLE_NETWORK;

typedef struct _DOT11_SSID {
ULONG uSSIDLength;
UCHAR ucSSID[32];
} DOT11_SSID, *PDOT11_SSID;


'-----Enumeration-----
typedef enum _DOT11_BSS_TYPE
{
dot11_BSS_type_infrastructure,
dot11_BSS_type_independent,
dot11_BSS_type_any
}DOT11_BSS_TYPE, *PDOT11_BSS_TYPE;

typedef DWORD WLAN_REASON_CODE, *PWLAN_REASON_CODE;

typedef enum _DOT11_PHY_TYPE
{
dot11_phy_type_unknown,
dot11_phy_type_any,
dot11_phy_type_fhss,
dot11_phy_type_dsss,
dot11_phy_type_irbaseband,
dot11_phy_type_ofdm,
dot11_phy_type_hrdsss,
dot11_phy_type_erp,
dot11_phy_type_IHV_start,
dot11_phy_type_IHV_end
}DOT11_PHY_TYPE, *PDOT11_PHY_TYPE;

typedef enum _DOT11_AUTH_ALGORITHM
{
DOT11_AUTH_ALGO_80211_OPEN,
DOT11_AUTH_ALGO_80211_SHARED_KEY,
DOT11_AUTH_ALGO_WPA,
DOT11_AUTH_ALGO_WPA_PSK,
DOT11_AUTH_ALGO_WPA_NONE,
DOT11_AUTH_ALGO_RSNA,
DOT11_AUTH_ALGO_RSNA_PSK,
DOT11_AUTH_ALGO_IHV_START,
DOT11_AUTH_ALGO_IHV_END
}DOT11_AUTH_ALGORITHM, *PDOT11_AUTH_ALGORITHM;

typedef enum _DOT11_CIPHER_ALGORITHM
{
DOT11_CIPHER_ALGO_NONE,
DOT11_CIPHER_ALGO_WEP40,
DOT11_CIPHER_ALGO_TKIP,
DOT11_CIPHER_ALGO_CCMP,
DOT11_CIPHER_ALGO_WEP104,
DOT11_CIPHER_ALGO_WPA_USE_GROUP,
DOT11_CIPHER_ALGO_RSN_USE_GROUP,
DOT11_CIPHER_ALGO_WEP,
DOT11_CIPHER_ALGO_IHV_START,
DOT11_CIPHER_ALGO_IHV_END
}DOT11_CIPHER_ALGORITHM, *PDOT11_CIPHER_ALGORITHM;




*** Sent via Developersdex http://www.develop... ***
6 Answers

zaimoni

2/23/2008 10:33:00 PM

0

On 2008-02-23 09:20:31, Risto Saarelma <rsaarelm@gmail.com> wrote:

> On 2008-02-13, Jeff Lait wrote:
> > His hatred of static types seems entirely misplaced. I think he hates
> > the excessive boiler plating most static type implementations impose.
> > Having had the opportunity to use Haskell recently, it really shows
> > why static types don't require any extra typing. Calling static types
> > "meta-data" is like calling unit tests "meta-data".
>
> As far as I've been able to tell, Yegge's issues with static typing are
> a bit more subtle and have to do with static type systems' difficulties
> in doing reflection. This makes it difficult to do all sorts of
> metaprogramming tricks and hacks you can find in Lisp and Smalltalk for
> example.
>
> One example of such a trick is hot-swapping running code. A rant about
> this: http://steve-yegge.blogspot.com/2007/01/pinocchio-pr...

Interesting read (and one which has much useful thought regardless of my
personal bias).

I would suggest that hot-swapping (self-modifying) code is even more limited by
not having a realtime source compiler/interpreter, in conjunction with
incremental linking. That is, the key element of hot-swapping code is having
an eval technique (using JavaScript/Perl notation). The equivalent flexibility
for a static-typed language would be to invoke a compiler and then link in the
just-compiled function in real-time, but a first step would be dynamic loading
of modules/plugins.

I think we have this already for byte-code compiled languages (e.g., Perl), but
machine-compiled languages aren't quite there yet.

Martin Read

2/23/2008 11:24:00 PM

0

Kenneth 'Bessarion' Boyd <zaimoni@zaimoni.com> wrote:
>The equivalent flexibility for a static-typed language would be to
>invoke a compiler and then link in the just-compiled function in
>real-time, but a first step would be dynamic loading of
>modules/plugins.

It's called dlopen(), and it's specified in POSIX 1003.1-2003.
--
\_\/_/ some girls wander by mistake into the mess that scalpels make
\ / are you the teachers of my heart? we teach old hearts to break
\/ --- Leonard Cohen, "Teachers"

Simon Richard Clarkstone

2/25/2008 6:45:00 PM

0

Risto Saarelma wrote:
> On 2008-02-13, Jeff Lait <torespondisfutile@hotmail.com> wrote:
>> His hatred of static types seems entirely misplaced. I think he hates
>> the excessive boiler plating most static type implementations impose.
>> Having had the opportunity to use Haskell recently, it really shows
>> why static types don't require any extra typing. Calling static types
>> "meta-data" is like calling unit tests "meta-data".
>
> As far as I've been able to tell, Yegge's issues with static typing are
> a bit more subtle and have to do with static type systems' difficulties
> in doing reflection. This makes it difficult to do all sorts of
> metaprogramming tricks and hacks you can find in Lisp and Smalltalk for
> example.
>
> One example of such a trick is hot-swapping running code. A rant about
> this: http://steve-yegge.blogspot.com/2007/01/pinocchio-pr...

I wonder if he thinks it counts when you can: save a module's precise
state, completely unload it, and reload the new version, which accepts
the old state and continues. There is a library to do that in Haskell
(I forget what it is called). It is an easier technique than in other
languages as Haskell's use of mutable state is constrained. With little
change, the state-saving for reloading a module can be made to serialise
the entire application state to disk.

Also, "traditional" Forth starts off with a dictionary that contains the
built-in words and the compiler, and applications are compiled and
linked directly on top of it; they extend the existing dictionary by
adding words to it. This is all done by interpreting arbitrary Forth
code, so there is no "boundary" between built-in words, the compiler,
and applications words, and no need for relocatable object code. Rather
like his beloved LISP.

--
src

Simon Richard Clarkstone

2/25/2008 6:53:00 PM

0

Simon Richard Clarkstone wrote:
> Risto Saarelma wrote:
>> One example of such a trick is hot-swapping running code. A rant about
>> this: http://steve-yegge.blogspot.com/2007/01/pinocchio-pr...
>
> I wonder if he thinks it counts when you can: save a module's precise
> state, completely unload it, and reload the new version, which accepts
> the old state and continues. There is a library to do that in Haskell
> (I forget what it is called).

Oops! As (the infamous) Philippa says in the first comment, it is
called hs-plugins:

http://www.cse.unsw.edu.au/~dons/h...

--
src

Jeff Lait

2/25/2008 8:48:00 PM

0

On Feb 23, 3:20 am, Risto Saarelma <rsaar...@gmail.com> wrote:
> On 2008-02-13, Jeff Lait <torespondisfut...@hotmail.com> wrote:
>
> > His hatred of static types seems entirely misplaced. I think he hates
> > the excessive boiler plating most static type implementations impose.
> > Having had the opportunity to use Haskell recently, it really shows
> > why static types don't require any extra typing. Calling static types
> > "meta-data" is like calling unit tests "meta-data".
>
> As far as I've been able to tell, Yegge's issues with static typing are
> a bit more subtle and have to do with static type systems' difficulties
> in doing reflection. This makes it difficult to do all sorts of
> metaprogramming tricks and hacks you can find in Lisp and Smalltalk for
> example.
>
> One example of such a trick is hot-swapping running code. A rant about
> this:http://steve-yegge.blogspot.com/2007/01/pinocchio-pr...

First, I think that static typing has little to do with being able to
make a system that doesn't need to reboot or can be hotswapped. We
already mentioned Edit and Continue in MSVC++, which clearly
demonstrates it is not impossible to build such a system.

His rant, while interesting, doesn't in the quick skim I gave it
address the true downfall of systems that never reboot. If you go too
long without rebooting, the system won't be rebootable. This is why
console games are limited as a FEATURE, not a mistake. The entire
design philosophy of console games and hardware is the blank-slate
starting conditions. This makes it practical to guarantee that the
system *will* work *every* time you run it. Very important when your
code is burned on a ROM.

It used to be very fashionable to have year long uptimes. It seems
the consensus now is to instead intentionally reboot systems to make
sure they are not accumulating magic cruft that prevents them from
being rebooted. I've had my experience of linux boxes that decided
not to power on again because one too many patch was run on the live
system.

The other big problem is that we don't need many systems. I don't
want Nethack to have a full shell - that is what my actual command
line shell is! Likewise, it would be a misfeature to have C++ itself
be it's own OS (like smalltalk or LISP) - I already have a perfectly
good OS, thank you very much.

I recently embarked in some Haskell work and will note that I've used
solely the command line compiler. First, the interpreter is too slow
to test against, second, programming in the interpreter means losing
vi, working in a line by line mode as if I were editing the source in
edlin. So while Haskell may (or may not) be "shell complete", I
really couldn't care less personally.
--
Jeff Lait
(POWDER: http://www.zincland....)

zaimoni

2/25/2008 9:37:00 PM

0

On 2008-02-25 21:47:43, Jeff Lait <torespondisfutile@hotmail.com> wrote:

> On Feb 23, 3:20 am, Risto Saarelma wrote:
> > On 2008-02-13, Jeff Lait wrote:
> >
> > > His hatred of static types seems entirely misplaced. I think he hates
> > > the excessive boiler plating most static type implementations impose.
> > > Having had the opportunity to use Haskell recently, it really shows
> > > why static types don't require any extra typing. Calling static types
> > > "meta-data" is like calling unit tests "meta-data".
> >
> > As far as I've been able to tell, Yegge's issues with static typing are
> > a bit more subtle and have to do with static type systems' difficulties
> > in doing reflection. This makes it difficult to do all sorts of
> > metaprogramming tricks and hacks you can find in Lisp and Smalltalk for
> > example.
> >
> > One example of such a trick is hot-swapping running code. A rant about
> > this:http://steve-yegge.blogspot.com/2007/01/pinocchio-pr...
>
> First, I think that static typing has little to do with being able to
> make a system that doesn't need to reboot or can be hotswapped. We
> already mentioned Edit and Continue in MSVC++, which clearly
> demonstrates it is not impossible to build such a system.

Edit and Continue in MSVC++ isn't relevant to the transhumanist religious slant
Steve took on hot-swapping. What he wants is for the program itself to be able
to generate a function, "compile it", and hotswap it in. This is almost
*essential* to actually realize a Vingean Singularity.

MSVC++ Edit and Continue is entirely programmer-controlled. But static typing
has little theoretical significance with program-controlled hotswapping of code;
it has *much* practical significance since so far only the byte-code compiled
languages have the eval capability that allows it. DLLs/plugins are a
second-rate hack.

> His rant, while interesting, doesn't in the quick skim I gave it
> address the true downfall of systems that never reboot. If you go too
> long without rebooting, the system won't be rebootable. ...

Also note that rebooting allows practical immortality for materialist AIs: dump
state on old machine, restart with that state on new machine. The
awareness-process discontinuity could well be no worse than sleep or anesthesia
is for us.

The objections he posits *assume* that a computer AI would be dualist
metaphysics, which is not at all clear. Not only do we know whether *we* use
dualist metaphysics (and if so, that may merely be a limited definition of
"matter and energy"), even if that were granted that would not prove that a
materialist AI was unconstructable.