Juergen Lock wrote:
> In article <[EMAIL PROTECTED]> you write:
> >This is a multi-part message in MIME format.
> >--------------A9463D0EE5C61FE8601BAA15
> >Content-Type: text/plain; charset=us-ascii
> >Content-Transfer-Encoding: 7bit
> >
> >Changelog:
> >* Got rid using PROFILE to get SCSI info from wine.conf
>
> Well, are you sure you want to do that, unconditionally?
Well, since PROFILE_GetWineIniString (or whatever the hell it was, not
looking at the source right now) is not supported except for in the main
thread now.. it seemed like a good idea.
>
> >* Read scsi info from /proc/scsi/scsi
>
> ...because /proc/scsi is a linuxism.
>
So is the ASPI DLL for now.. so I wouldn't worry about it.
>
> >* Added file include/winescsi.h
> >* Added file dlls/wnaspi32/aspi.c (Functions that wnaspi32 uses, but not
> >exports)
> >* Updated dlls/winaspi/winaspi16.c to use winescsi.h
> >* Added setting of a reasonable timeout when opening a SCSI device (5
> >minutes, defined in winescsi.h)
>
> Not sure it would matter in many cases (at least as long as the
> target in question supports disconnect), but there are scsi commands
> that can take _much_ longer than 5 minutes. think of tapes...
>
Wasn't too concerned seeing as how the linux default is 1 minute (which is
REALLY bad).. I think the ASPI spec is like 3 days or something insane.
I can make another patch to get this stuff from the registry.
>
> >...
> >Because we are now reading info from /proc/scsi/scsi when WNASPI32 is
> >loaded, this will cut down on the number of newsgroup messages about
> >"Well I have my CD-R drive letter set up, why won't it burn a disc!"
>
> Well thats a good thing for sure, but wine should still keep the
> wine.conf reading at least for those systems that don't have a
> /proc/scsi. (even if it still doesn't know how to talk to the scsi
> bus anywhere except for linux there's no reason that couldn't change.)
>
Actually, I was going to go ahead and provide a registry setting for
overriding this stuff later on.
>
> (Oh and if you're worried about wasted discs, why not just write
> it with cdrecord/cdrdao instead? no need for wintendo stuff just
> to burn a CD!)
>
Okay.... when you get a Matsushita CW-7501 to work with cdrecord, please
e-mail me. It is a fairly old model but I have been quite happy with it and
don't want to get rid of it.
>
> Regards,
> --
> Juergen Lock <[EMAIL PROTECTED]>
> (remove dot foo from address to reply)
Again, this was kind of a preliminary patch to at least get ASPI to a more
workable level.
I am not entirely sure about which way to go with ASPI. No one has seemed
really interested in supporting it on anything other than Linux. I also
don't think that there is enough of a concern to warrant some OS-independent
interface to SCSI being added to Wine. The best thing for people to do if
they want ASPI to work on BSD or Solaris or whatever is to simply take the
ASPI code and add in support for <insert OS here>.
I have looked at the code to libscg (the thing that comes with cdrecord) and
frankly I wouldn't touch that code with a ten foot pole, that and it's GPL
anyway so it is definitely out of the question for Wine.
Basically, I am taking an if it ain't broke don't fix it approach. I have
yet to see an app that even requires being able to queue commands and have
the results returned with a callback. I even have some code which allows
this but it's so not necessary there is no point in using it, and it's quite
a bit of overkill. I could probably post it somewhere if anyone really
needed it though.
-Dave
P.S. I did send in a slightly newer version of this patch after alexandre
merged WINASPI and WNASPI32 with the previous patch.
