Unable to use drive number 32 with some functions

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Unable to use drive number 32 with some functions

Damien Guibouret
Hello,

I found a small problem in ioctl code that leads to drive number 32 to not be
usable with device related functions (int 0x21, ah=0x44..) and leading to
returning information about another drive without signaling any error. As I
suppose this is not widely used (drive 27 to 32 are most often not known by
users), I think this is quite minor. I wrote a patch, but did not test nor even
compile it. In this patch I keep some code that from interface point of view is
wrong but that is the way I understood the "NDN" related comment.

Regards,

Damien

--- ioctl.c.orig        2015-04-26 21:01:18.000000000 +0200
+++ ioctl.c     2015-04-26 21:26:48.000000000 +0200
@@ -164,6 +164,7 @@
      {
        struct dpb FAR *dpbp;
        unsigned attr;
+      BYTE used_drive;
  /*
     This line previously returned the deviceheader at r->bl. But,
     DOS numbers its drives starting at 1, not 0. A=1, B=2, and so
@@ -173,9 +174,18 @@
   */
  /* JPP - changed to use default drive if drive=0 */
  /* JT Fixed it */
-
-      /* NDN feeds the actual ASCII drive letter to this function */
-      dpbp = get_dpb((r->BL & 0x1f) == 0 ? default_drive : (r->BL & 0x1f) - 1);
+      if (r->BL == 0)
+        used_drive = default_drive;
+      else if ((r->BL >= 1) && (r->BL <= 32))
+        used_drive = r->BL - 1;
+      else if (((r->BL >= 'A') && (r->BL <= 'Z')) ||
+               ((r->BL >= 'a') && (r->BL <= 'z')))
+        /* NDN feeds the actual ASCII drive letter to this function */
+        used_drive = (r->BL & 0x1f) - 1;
+      else
+        return DE_INVLDDRV;
+
+      dpbp = get_dpb(used_drive);
        if (dpbp)
        {
          CharReqHdr.r_unit = dpbp->dpb_subunit;
@@ -196,7 +206,7 @@
          {
            /* note from get_dpb()                            */
            /* that if cdsp == NULL then dev must be NULL too */
-          struct cds FAR *cdsp = get_cds1(r->BL & 0x1f);
+          struct cds FAR *cdsp = get_cds(used_drive);
            if (cdsp == NULL)
              return DE_INVLDDRV;
            if (cdsp->cdsFlags & CDSSUBST)

------------------------------------------------------------------------------
One dashboard for servers and applications across Physical-Virtual-Cloud
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
_______________________________________________
Freedos-kernel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Unable to use drive number 32 with some functions

perditionc

Thank you.  I will try to get a fix implemented this week.  Your patch corrects supporting the 32nd drive if provided as value 1 thru 32 (0 is default) but still doesn't handle if passed as ascii value ` (0x60).

Jeremy

On Apr 26, 2015 3:51 PM, "Damien Guibouret" <[hidden email]> wrote:
>
> Hello,
>
> I found a small problem in ioctl code that leads to drive number 32 to not be
> usable with device related functions (int 0x21, ah=0x44..) and leading to
> returning information about another drive without signaling any error. As I
> suppose this is not widely used (drive 27 to 32 are most often not known by
> users), I think this is quite minor. I wrote a patch, but did not test nor even
> compile it. In this patch I keep some code that from interface point of view is
> wrong but that is the way I understood the "NDN" related comment.
>
> Regards,
>
> Damien
>
> --- ioctl.c.orig        2015-04-26 21:01:18.000000000 +0200
> +++ ioctl.c     2015-04-26 21:26:48.000000000 +0200
> @@ -164,6 +164,7 @@
>       {
>         struct dpb FAR *dpbp;
>         unsigned attr;
> +      BYTE used_drive;
>   /*
>      This line previously returned the deviceheader at r->bl. But,
>      DOS numbers its drives starting at 1, not 0. A=1, B=2, and so
> @@ -173,9 +174,18 @@
>    */
>   /* JPP - changed to use default drive if drive=0 */
>   /* JT Fixed it */
> -
> -      /* NDN feeds the actual ASCII drive letter to this function */
> -      dpbp = get_dpb((r->BL & 0x1f) == 0 ? default_drive : (r->BL & 0x1f) - 1);
> +      if (r->BL == 0)
> +        used_drive = default_drive;
> +      else if ((r->BL >= 1) && (r->BL <= 32))
> +        used_drive = r->BL - 1;
> +      else if (((r->BL >= 'A') && (r->BL <= 'Z')) ||
> +               ((r->BL >= 'a') && (r->BL <= 'z')))
> +        /* NDN feeds the actual ASCII drive letter to this function */
> +        used_drive = (r->BL & 0x1f) - 1;
> +      else
> +        return DE_INVLDDRV;
> +
> +      dpbp = get_dpb(used_drive);
>         if (dpbp)
>         {
>           CharReqHdr.r_unit = dpbp->dpb_subunit;
> @@ -196,7 +206,7 @@
>           {
>             /* note from get_dpb()                            */
>             /* that if cdsp == NULL then dev must be NULL too */
> -          struct cds FAR *cdsp = get_cds1(r->BL & 0x1f);
> +          struct cds FAR *cdsp = get_cds(used_drive);
>             if (cdsp == NULL)
>               return DE_INVLDDRV;
>             if (cdsp->cdsFlags & CDSSUBST)
>
> ------------------------------------------------------------------------------
> One dashboard for servers and applications across Physical-Virtual-Cloud
> Widest out-of-the-box monitoring support with 50+ applications
> Performance metrics, stats and reports that give you Actionable Insights
> Deep dive visibility with transaction tracing using APM Insight.
> http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
> _______________________________________________
> Freedos-kernel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/freedos-kernel


------------------------------------------------------------------------------
One dashboard for servers and applications across Physical-Virtual-Cloud
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
_______________________________________________
Freedos-kernel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Unable to use drive number 32 with some functions

Damien Guibouret
Hello,

That's right, I was not expecting NDN will use it as it is already out of the spec.
You can change the

else if (((r->BL >= 'A') && (r->BL <= 'Z')) ||
          ((r->BL >= 'a') && (r->BL <= 'z')))
   /* NDN feeds the actual ASCII drive letter to this function */
   used_drive = (r->BL & 0x1f) - 1;

into

else if (((r->BL >= 'A') && (r->BL <= '`')) ||
          ((r->BL >= 'a') && (r->BL <= 'z')))
   /* NDN feeds the actual ASCII drive letter to this function */
   used_drive = (r->BL - 1) & 0x1f;

I think the lowercase case can remain as it is (there is no correspondance
between lower and upper case for letters above 'z' and more over it goes outside
of 7 bits ASCII range).

Regards,

Damien

[hidden email] wrote:

> Thank you.  I will try to get a fix implemented this week.  Your patch
> corrects supporting the 32nd drive if provided as value 1 thru 32 (0 is
> default) but still doesn't handle if passed as ascii value ` (0x60).
>
> Jeremy
>
> On Apr 26, 2015 3:51 PM, "Damien Guibouret" <
> [hidden email]> wrote:
>
>>Hello,
>>
>>I found a small problem in ioctl code that leads to drive number 32 to
>
> not be
>
>>usable with device related functions (int 0x21, ah=0x44..) and leading to
>>returning information about another drive without signaling any error. As
>
> I
>
>>suppose this is not widely used (drive 27 to 32 are most often not known
>
> by
>
>>users), I think this is quite minor. I wrote a patch, but did not test
>
> nor even
>
>>compile it. In this patch I keep some code that from interface point of
>
> view is
>
>>wrong but that is the way I understood the "NDN" related comment.
>>
>>Regards,
>>
>>Damien
>>
>>--- ioctl.c.orig        2015-04-26 21:01:18.000000000 +0200
>>+++ ioctl.c     2015-04-26 21:26:48.000000000 +0200
>>@@ -164,6 +164,7 @@
>>      {
>>        struct dpb FAR *dpbp;
>>        unsigned attr;
>>+      BYTE used_drive;
>>  /*
>>     This line previously returned the deviceheader at r->bl. But,
>>     DOS numbers its drives starting at 1, not 0. A=1, B=2, and so
>>@@ -173,9 +174,18 @@
>>   */
>>  /* JPP - changed to use default drive if drive=0 */
>>  /* JT Fixed it */
>>-
>>-      /* NDN feeds the actual ASCII drive letter to this function */
>>-      dpbp = get_dpb((r->BL & 0x1f) == 0 ? default_drive : (r->BL &
>
> 0x1f) - 1);
>
>>+      if (r->BL == 0)
>>+        used_drive = default_drive;
>>+      else if ((r->BL >= 1) && (r->BL <= 32))
>>+        used_drive = r->BL - 1;
>>+      else if (((r->BL >= 'A') && (r->BL <= 'Z')) ||
>>+               ((r->BL >= 'a') && (r->BL <= 'z')))
>>+        /* NDN feeds the actual ASCII drive letter to this function */
>>+        used_drive = (r->BL & 0x1f) - 1;
>>+      else
>>+        return DE_INVLDDRV;
>>+
>>+      dpbp = get_dpb(used_drive);
>>        if (dpbp)
>>        {
>>          CharReqHdr.r_unit = dpbp->dpb_subunit;
>>@@ -196,7 +206,7 @@
>>          {
>>            /* note from get_dpb()                            */
>>            /* that if cdsp == NULL then dev must be NULL too */
>>-          struct cds FAR *cdsp = get_cds1(r->BL & 0x1f);
>>+          struct cds FAR *cdsp = get_cds(used_drive);
>>            if (cdsp == NULL)
>>              return DE_INVLDDRV;
>>            if (cdsp->cdsFlags & CDSSUBST)
>>
>>
>

------------------------------------------------------------------------------
One dashboard for servers and applications across Physical-Virtual-Cloud
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
_______________________________________________
Freedos-kernel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Loading...