[prev in list] [next in list] [prev in thread] [next in thread] 

List:       wine-devel
Subject:    ASPI stuff.
From:       David Elliott <dfe () netnitco ! net>
Date:       1999-11-29 18:11:39
[Download RAW message or body]

Hi All,

I've been looking at the code in dlls/wnaspi32/ and include/aspi.h and
have a few comments.

A while back someone added a hack that defined malloc(x) to be
HeapAlloc(GetProcessHeap(),0,x).  A little bit before that I had started
playing with the SCSI code trying to get my CD-R to work correctly (It's
a Matsushita CW-7501 if anyone cares).

The applications I am using are from GoldenHawk technologies and seem to
be fairly stable.  GoldenHawk also makes a set of Win32 console apps
that do the same things as CDR-Win.  The problem I am having is that the
thing will write a disc just fine, but it will not correctly finalize a
session.  I did get it to work by writing an ISO image (RH 6.1) to a
disc and not finalizing (using CDR-Win).  I then rebooted and used the
console program to finalize the session.  The disc works fine.  I have
also tried using the console program vs. the GUI program and neither one
can correctly finalize a disc.

In include/aspi.h there is some code from the Linux header files (so you
don't need kernel headers to compile Wine).  I would like to update this
structure to the 2.2.x structure instead of the 2.0.30 structure being
used now.  The added benefits are {target,host,driver)_status fields.
These fields are part of the 31 bits reserved in the 2.0.x structure.  I
believe the way to go would be to use a runtime check of the kernel
version, and if 2.2.x is being used, then translate the Linux status
codes to ASPI status codes.

The other change I would like to make is to change the word in to out
and the word out to in.  According to the ASPI documentation going from
the HOST to the TARGET is sending data out.  Going from TARGET to HOST
is incoming data.  At least that is my interpretation of it.  Not sure
why these terms are reversed in the code.

Finally, correct me if I am wrong, but we really should not be using
system calls like malloc and free (hence the define hack).  Nor should
we be using any system calls except those that actually talk to Linux
(such as reading from the sgX device).  I am assuming that using
read/write on the Linux file descriptor is correct behavior.  But using
memset does not seem like a good idea since this is Windows code (for
the most part) not Linux code.

That also begs the question if calls to Linux should be in this code at
all.  AFAIK calling the C library is not thread safe, so should the read
and write calls be protected with some sort of spinlock (like a critical
section or something)?

If no one has any objections I will start sending patches as follows:
1. Anything that can call a Windows function instead of a Linux function
should call the Windows function (after all, this is Windows code not
Linux code).
2. Change in to out and vice-versa-- unless someone can give me a good
explanation for this, but if I'm going to be working on the code I'd
rather exchange the terms and be less confused.
3. Add support for Linux 2.2.x status codes.

Somewhere in there I'll also add any thread-safety stuff that is needed
if someone recommends it.

And as far as licensing the code goes, I would be more than happy with
an X11 or Modified BSD or LGPL or anything like it.  I'd prefer the
license to at least be compatible with one (or more) of those.

Dave.


=========================================================================

[prev in list] [next in list] [prev in thread] [next in thread]