VxD's and hardlocks

Hi,

I am trying to run a point of sale app on wine.
It uses a hard lock on the parallel port from
www.proteq.com .

This hard lock is implemented as a proteq.DLL , proteq.VxD pair.

I read the documentation and browsed the mail lists
and understood that VxD's have to be rewritten to work
in wine. It is impossible to run a native VxD due
to low level implementation conflicts between nix'es
and Windows. All VxD's are builtin so to speak.

I understand that www.proteq.com supports linux.

Therefore, for my windows app to work under wine without modification, I would
have to create a builtin proteq.DLL that accesses the linux's libs written by
www.proteq.com.

Is this correct?

Thanks!

Miguel

-------------------------------------------------
This mail sent through IMP: webmail.vmn.com.br

[Uwe Bonnes]

> > > > > "list" == list   writes:

list> Hi, I am trying to run a point of sale app on wine.  It uses a
    list> hard lock on the parallel port from www.proteq.com .

list> This hard lock is implemented as a proteq.DLL , proteq.VxD pair.

list> I read the documentation and browsed the mail lists and understood
    list> that VxD's have to be rewritten to work in wine. It is impossible
    list> to run a native VxD due to low level implementation conflicts
    list> between nix'es and Windows. All VxD's are builtin so to speak.

list> I understand that www.proteq.com supports linux.

list> Therefore, for my windows app to work under wine without
    list> modification, I would have to create a builtin proteq.DLL that
    list> accesses the linux's libs written by www.proteq.com.

list> Is this correct?

You must either built a proteq.VxD replacement which is accessed by a
possibly native, or you must rewrite proteq.DLL which either no longer does
any hardware security checks or which uses Unix methods for that
access. Both approaches require proteq to cooperate, something that I doubt
will happen....

Bye

[List vmn]

> You must either built a proteq.VxD replacement which is accessed by a
> possibly native, or you must rewrite proteq.DLL which either no longer does
> any hardware security checks or which uses Unix methods for that
> access. Both approaches require proteq to cooperate, something that I doubt
> will happen....

Uwe,

Thanks for your help, it is what I expected.

Miguel