On Fri, Mar 10, 2000 at 11:51:53PM -0600, David Elliott wrote:
> 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:
> > > 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.
>
Ah yes, the PROFILE_GetWineIniString now just calls the Reg*, thats true.
> 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).
>
Thanx!
> 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. ...
Ah ok, so you're still reading the config file, just via Reg* calls...
> > 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.
Well if you're writing _audio_ CDs then you probably want cdrdao not
cdrecord. (actually cdrecord now has some DAO option too but i suspect
cdrdao may still work better, at least thats what i use. look here:
http://www.ping.de/sites/daneb/cdrdao.html)
> 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.
>
No TAO is only good for data CDs, i know that... :)
> I have sort of a hobby of cutting music for a friend of mine who owns a dance
> studio.
Hmm pity you're so far away, i'd like to listen to what you're
cutting there... (I only have this new `hobby' of recording mixes off
the air, actually i'm just doing that as i type, and writing a CD at the
same time too.)
> 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.
>
Have you looked at Gmurf? http://www.epita.fr:8000/~epx/projets/gmurf/
Looks like to do some cutting it may be enough, it only doesn't yet
work right on FreeBSD...
> 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.
>
Also windows programs like GoldWave and Cakewalk aren't cheap either,
right?
> > > 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.
*ugh*, i didn't know that...
> 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).
aa-ha... :(
> 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).
>
err...
> 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.
Yes FreeBSD uses CAM, and i would say this is the way SCSI should be done.
Regards,
--
Juergen Lock <[EMAIL PROTECTED]>
(remove dot foo from address to reply)
