Q: Unimplemented control 256 for VxD device VNETBIOS

[Michael Riedel]

I am going to migrate the EDA software environment from Windows NT to 
Linux but I have still some software components requireing Windows. 
That's why I use Wine. I own and use some software packages licensed to 
a valid MAC address (flexlm MAC based license) and the corresponding NIC 
is present in the Linux system.

Using wine-20010824 I get the following message:

fixme:win32:DeviceIoControl Unimplemented control 256 for VxD device 
VNETBIOS

I scanned the Web resources and studied the file 'win32/device.c' a 
little bit but I got no answers to my questions. Is there already a 
solution/implementation for this service? I am also ready to contribute 
(at least I hope I'm able to do so and it would be fun ;-) but I need 
some advice (docus, especially related to the VNETBIOS VxD and some 
general hints).

I'm looking forward for any hints.

Michael

[Uwe Bonnes]

> > > > > "Michael" == Michael Riedel  writes:

Michael> I am going to migrate the EDA software environment from Windows
    Michael> NT to Linux but I have still some software components
    Michael> requireing Windows.  That's why I use Wine. I own and use some
    Michael> software packages licensed to a valid MAC address (flexlm MAC
    Michael> based license) and the corresponding NIC is present in the
    Michael> Linux system.

Michael> Using wine-20010824 I get the following message:

Michael> fixme:win32:DeviceIoControl Unimplemented control 256 for VxD
    Michael> device VNETBIOS

Michael> I scanned the Web resources and studied the file
    Michael> 'win32/device.c' a little bit but I got no answers to my
    Michael> questions. Is there already a solution/implementation for this
    Michael> service? I am also ready to contribute (at least I hope I'm
    Michael> able to do so and it would be fun ;-) but I need some advice
    Michael> (docus, especially related to the VNETBIOS VxD and some general
    Michael> hints).

Michael> I'm looking forward for any hints.

These FLEX LMs are always a problem.

I guess, the license isn't bind to a physical dongle on the parallel
port. So one can conclude that the software tries to read the MAC. This
probably happens in a NETBIOS.DLL call which then probably calls the
NETBIOS.VXD.  I propose you run with --debugmsg +relay,+snoop,+vxd and try
to decipher what is going on before that failing VXD call. In the easiest
approach, you can build a fake builtin NETBIOS DLL, with the appropriate
function returning the MAC in the first approach hardcoded or really reading
it with OS calls.

If running with --debugmsg +snoop crashes, I have a hack that may help
there. I have also patches for an empty NETBIOS dll.

However I guess that this probably isn't enough to make FLEX LM happy.

Bye

[Michael Riedel]

Thank you all for your thoughts, it's a pleasure.
> I guess, the license isn't bind to a physical dongle on the parallel
> port. So one can conclude that the software tries to read the MAC.

For sure, the (my) license is based on the MAC address (flexLM supports 
different license approaches as you mentioned).
> NETBIOS.VXD.  I propose you run with --debugmsg +relay,+snoop,+vxd and try
> to decipher what is going on before that failing VXD call. In the easiest

Done. Please find the messages in the attachement. I shrinked the 7 MB 
file to those lines around the error message. But because I'm a 
Windows's internal newbie it'll take me some hours to understand the 
messages. But anyhow I'll investigate the messages later but also any 
help is very welcome.

Michael--

[Andreas Mohr]

On Thu, Oct 18, 2001 at 02:39:44PM +0200, Michael Riedel wrote:
> Thank you all for your thoughts, it's a pleasure.

:-)
> > I guess, the license isn't bind to a physical dongle on the parallel
> > port. So one can conclude that the software tries to read the MAC.
>
> For sure, the (my) license is based on the MAC address (flexLM supports 
> different license approaches as you mentioned).
> > NETBIOS.VXD.  I propose you run with --debugmsg +relay,+snoop,+vxd and try
> > to decipher what is going on before that failing VXD call. In the easiest
>
> Done. Please find the messages in the attachement. I shrinked the 7 MB 
> file to those lines around the error message. But because I'm a 
> Windows's internal newbie it'll take me some hours to understand the 
> messages. But anyhow I'll investigate the messages later but also any 
> help is very welcome.

--> search.microsoft.com

Boy, am I glad that finally somebody is thinking about implementing certain
VNETBIOS aspects...

I've been lobbying that for months now to several people, without any success
so far.
(I don't have any program requesting this, so I couldn't test it anyway)