Ove Kaaven wrote:
> On Fri, 3 Mar 2000, David Elliott wrote:
>
> > Here is the new DOS ASPI layer, it is now located in msdos/dosaspi.c.
> > This basically loads up WNASPI32 and translates from DOS ASPI to
> > WNASPI32 when appropriate. In the SC_EXEC_SCSI_CMD case it actually
> > puts the DOS pointer to the original DOS SRB just after the sense info
> > in the WNASPI32 SRB (that way the PostProc can use it).
>
> Hmm.
This should be valid according to the WNASPI32 spec, it doesn't say anything about
allocating a little extra memory past the sense buffer and using it for other
data. I assume this should work fine since WNASPI32 should not be writing past
what it thinks is the end of the allocated memory.
>
>
> > /* Now do posting */
> > if( lpPRB->SRB_Status == SS_SECURITY_VIOLATION )
> > {
> > /* SS_SECURITY_VIOLATION isn't defined in DOS ASPI */
> > TRACE("Returning SS_NO_DEVICE for SS_SECURITY_VIOLATION\n");
> > lpPRB->SRB_Status = SS_COMP;
> > lpPRB->SRB_Status = SS_NO_DEVICE;
> > }
>
> why two lpPRB->SRB_Status assignments?
>
Originally I commented out the SS_NO_DEVICE and put in SS_COMP until I realized
that this code wasn't getting called at all since I had already HeapFreed the
lpPRB and so lpPRB->SRB_Status was 0 (funny, I would have hoped it segfaulted...
guess not). Then I uncommented SS_NO_DEVICE and didn't comment out SS_COMP (since
it really has no effect other than wasting processor cycles).
>
> > if( (lpSRB16->cmd.SRB_Flags & 0x1) && lpSRB16->cmd.SRB_PostProc )
> > {
> > SEGPTR spPRB = MapLS(lpSRB16);
> > TRACE("Calling PostProc\n");
> > Callbacks->CallASPIPostProc(lpSRB16->cmd.SRB_PostProc, ptrSRB);
> > UnMapLS(spPRB);
> > }
>
> This looks a lot like a win16 callback, not a DOS callback. For a real DOS
> callback, an example is found in msdos/int33.c. A synchronous callback
> would just use DPMI_CallRMProc, while an asynchronous callback (like
> PostProc would appear to be) would have to go through DOSVM_QueueEvent
> (which would interrupt the running DOS process when appropriate, then call
> the relay handler in a synchronous context, where DPMI_CallRMProc could be
> used).
Hmm.. it looks like a Win16 callback because it is. It's from the original
WINASPI code. I'll take a look at CallRMProc and do that instead.
>
>
> But it's complicated by the fact that the reason DOS ASPI exists in Wine
> in the first place, is that old Win16 apps (from the days before WINASPI
> existed) use DPMI calls to thunk down to DOS ASPI. For those,
> DOSVM_QueueEvent wouldn't work, since there would be no DOS process.
>
> But I suppose I could add some DOSVM logic to let DOSVM_QueueEvent call
> the relay handler directly if there's no running DOS process?
>
> It's just that I wonder how this Win16 PostProc business worked for
> DOS ASPI in the first place. Was it never used, or have I missed something
> biiig?
Okay, I understand that. If you want I can add a comment to the DOSASPI code
saying that Win16 processes using posting will not work because they don't have a
DOS process, if this matters to you, don't fix anything here, fix Wine to have a
DOS process for Win16 programs.
I think the reason this has never been caught is that most DOS programs poll. At
least the one I am using does. I have a strong feeling that that code has never
been used, and that's why it never got caught.
Also: http://www.goldenhawk.com/
They have demo versions of 16-bit (DOS), 32-bit (they call it does, but it's a
Win32 console app), and Win32 GUI CD-R tools. They have been invaluable when
trying to test this stuff out. The only problem I have now is that I need
something that actually calls WINASPI. I think I have an old copy of Corel
CD creator around here somewhere though.
Thanks,
Dave.
