It would us to help you if the code you posted at least compiled clean of simple typos.

1. $rasentry = Win32::API::Struct->New( 'RASENTRY' );

   The is no method New(...), it is new(...)

2. $ret = RasSetEntryProperties( $Phonebook, $Entry, $rasentry, (Win32::API::Struct::sizeof($rasentry), 0, 0);

   There is an extraneous left paren.

If you had enabled warnings (-w or use warnings;) then you would see that once the above typos are corrected, your code produces 938 lines of warnings.

These two

Useless use of hash element in void context at test.pl8 line 170.
Useless use of hash element in void context at test.pl8 line 349.
[download]

relate to these two lines where you have forgotten to add the assignment.

      $rasentry->{dwDialExtraSampleSeconds}; #170
      $rasentry->{dwDialExtraSampleSeconds}; #349
[download]

The other 936 come from Win32::API::Struct or Win32::API::Type. When a module starts producing large numbers of warnings like this, you can draw one of two conclusions: Either the module author ignored warnings and published a really crap module--which does happen, but for the most part not-- or, you are using it incorrectly.

For my part, I usually assume the latter, and I'm rarely disappointed:)

Picking out a few lines of your code and analysing them

• $rasentry->{dwfOptions} = $RASOPTIONS;

  You assigning a (psuedo-constant (uppercase)) value to one element of your newly created RASENTRY structure.

  Looking up the type of the dwfOptions field I find DWORD      dwfOptions;. That means it is a 32-bit unsigned numeric value.

  Looking at your definition of $RASOPTIONS I find

  $RASOPTIONS = "RASEO_IpHeaderCompression+RASEO_RemoteDefaultGateway+RA
  +SEO_SwCompression";
  [download]

  Which is a string!

  For Win32:API::Struct to be able to 'DWIM' this would require it to somehow know that this string is an equation that adds three values together.

  And know that those 3 values are represented by symbolic names that represent numeric values.

  And know that to translate those symbolic names to their underlying numeric values, that it much either look them up in a file (probably called ras.h) somewhere in the INCLUDE path for your C compiler--assuming you have one--or go online to MSDN and navigate to try and find the appropriate values--which is a nightmare task even with my (limited) human intelligence driving the process:)

• TCHAR      szAreaCode[ RAS_MaxAreaCode + 1 ];

  In this line, TCHAR is a typedef which Win32::API::Type.pm knows translates to the C type char.

  And this bit szAreaCode[ RAS_MaxAreaCode + 1 ] would tell a C compiler that the field named szAreaCode is an array ([...]) of char that can contain RAS_MaxAreaCode + 1 chars.

  The problem is that RAS_MaxAreaCode is another C defined constant that needs to be looked up in a header file somewhere, and the + 1 is a C compile-time constant equation which neither perl nor Win32::API::Struct has any knowledge of nor any mechanism for resolving to the underlying numeric values.

The upshot is that you will need to resolve these symbolic constants to their numeric values. There are several approaches to doing this, and it would be an interesting project to extend Win32::API to automate some more of this type of thing, but it would entail a great deal of work and would not be something to take on lightly.

I hope that this post won't offend you and will clarify some of the problems that you face in re-writing Win32::RASE to work with Win2K. None of the problems are insurmountable, but there is no readily available shortcut to the process.