Juergen Lock wrote:
> On Thu, Mar 09, 2000 at 09:39:05PM -0600, David Elliott wrote:
> > Juergen Lock wrote:
> >
> > > In article <[EMAIL PROTECTED]> you write:
>
> > > >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.
> >
> It is? sounds like thats just the change that broke things like
> eg the [serialports], and if its that then i can tell you it was
> already reverted.
In any case, it was mentioned that you can instead use the Registry functions to
read the key where wine stores it's config info.
>
> > >
> >
> > > >* 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.
> >
> Well my point was more along the lines of the profile reading code
> could still be useful for other systems when support for them is added
> later... (btw seems my subject was even more on the spot than i thought,
> the new aspi.c now won't even _build_ on anything non-linux anymore!)
>
Yeah.. I messed up on that ifdef linux. I'll send in a patch in a little bit
(soon as I am done reading the rest of the mail).
>
> > > >...
> > > >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.
> >
> Ok that should take care of that problem. (but btw at least I
> find editing a .ini-style textfile still easier than editing the
> registry... is there a real reason to move static configuration
> data into the registry when it doesn't have to be there to be
> compatible with the original windows?)
Actually, I meant a registry setting as in the one that Wine creates dynamically
at start up using the config file. I believe it was in
HKLM\Software\Wine\Wine\sectionname\name == value. Since Registry functions are
a core Windows thing, we should use them instead of PROFILE which is Wine only.
As I understand it, the ultimate goal is to have only windows functions and unix
functions available from Wine code.
>
> > >
> > > (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.
> >
> Oh, an old drive that cdrecord doesn't know about? ok in that
> case, sorry. (well i guess you could do a scsi trace of that
> program you're using to try to add support for the drive to
> cdrecord, if there's no other documentation...)
>
Actually, I did do that, and I now know how DAO on the drive works. I haven't
bothered with TAO because I hate track at once. Unfortunately, cdrecord doesn't
do DAO, so yet another reason not to use it. If CD record had DAO support
I could have support for the CW-7501 in it in probably a day. I could probably
do the same with TAO, but really don't want to since it doesn't help me for what
I need to do.
I have sort of a hobby of cutting music for a friend of mine who owns a dance
studio. So it is important to me to be able to create a perfect (that is
DAO) Audio CD. The other thing I'd like to see working is GoldWave, the audio
editor I use to do all the cutting.
Fortunately my SBLive is supported with open source drivers now, so I am
seriously considering putting some effort into getting stuff like GoldWave and
Cakewalk to work under Wine so I can play around making music like I used to.
> > 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.
>
> but that of course should only be a question of time as wine is
> getting more useful every day. (or, maybe we're just too busy
> fixing the regular `wine broken again on {insert-your-favourite-
> non-linux-OS}'? :) but that too could change when there'll be more
> of us as wine becomes more useful.)
>
Absolutely.. I'd love to see FreeBSD support, or even Solaris support.
>
> > I also
> > don't think that there is enough of a concern to warrant some OS-independent
> > interface to SCSI being added to Wine. ...
>
> now _that_ may well be true...
>
Yeah.. I am pretty sure that that is true.. SCSI interfaces are usually quite
similar, but some support very advanced queueing techniques, others don't. Some
(like ASPI) don't support the notion of a channel so each ha+chan combo is
considered a controller. Some are really bad attempts to capture the market away
from adaptec with a really bad interface to encourage programmers to write kernel
level drivers instead of user level passthrough stuff: (COUGH)SPTI(COUGH).
Furthermore, OS/2 supports ASPI directly (although only in code with IOPL, so you
need some sort of driver to authenticate user level programs and add another
layer of passthrough).
Supposedly the best implementation is CAM, which Linux does not do, but FreeBSD
does (IIRC). I would love to see someone add code for CAM, but since I don't
have a spare box laying around and really don't want to go through the hell that
VMware presents, I'll have to pass on this one myself.
Thanks,
-Dave
