All of lore.kernel.org
 help / color / mirror / Atom feed
* experimental LFN support for redirected drives
@ 2003-07-13 15:09 Bart Oldeman
  0 siblings, 0 replies; 5+ messages in thread
From: Bart Oldeman @ 2003-07-13 15:09 UTC (permalink / raw)
  To: linux-msdos

Hi,

I put a patch up (applies against 1.1.5.2 with a little fuzz, see
www.dosemu.org/testing) at
<http://sourceforge.net/tracker/index.php?func=detail&aid=738733&group_id=49784&atid=457450>

tested with various DJGPP utilities, 4DOS and win98 command.com. Neither
comcom nor freecom support LFNs.

If you know how to deal with patches and like to test it a little then
please let me know if it works.

Bart


^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: experimental LFN support for redirected drives
  2003-07-14 17:29 Stas Sergeev
@ 2003-07-14 18:07 ` Bart Oldeman
  0 siblings, 0 replies; 5+ messages in thread
From: Bart Oldeman @ 2003-07-14 18:07 UTC (permalink / raw)
  To: linux-msdos

On Mon, 14 Jul 2003, Stas Sergeev wrote:

> OK, I will do (trying right now:)
> The attached patch is intended to fix the
> problem. I don't have your test-case for it
> so I can only guess if it helps or works as
> expected.
> A quick test against a couple of DPMI progs
> shows no regressions.
> Does this help?

yes. This very much looks like the proper way to handle ints in DPMI, let
int.c worry about these things using do_int! Indeed, DJGPP ls now shows
long file names without my hack so your patch works.

Thanks
Bart


^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: experimental LFN support for redirected drives
@ 2003-07-14 17:29 Stas Sergeev
  2003-07-14 18:07 ` Bart Oldeman
  0 siblings, 1 reply; 5+ messages in thread
From: Stas Sergeev @ 2003-07-14 17:29 UTC (permalink / raw)
  To: linux-msdos

[-- Attachment #1: Type: text/plain, Size: 521 bytes --]

Hello.

Bart Oldeman wrote:
> INT 21 now just executes the DOS int21 and never reaches
> the DOSEMU revectored int21 code. I don't know if it's
> safe to transfer to f000:_BL*0x10 for every interrupt.
I am thinking about a less intrusive solution.

> Maybe you do?
OK, I will do (trying right now:)
The attached patch is intended to fix the
problem. I don't have your test-case for it
so I can only guess if it helps or works as
expected.
A quick test against a couple of DPMI progs
shows no regressions.
Does this help?

[-- Attachment #2: dpmi_int.diff --]
[-- Type: text/plain, Size: 2631 bytes --]

--- src/base/async/int.c	Sun Jun 15 03:01:24 2003
+++ src/base/async/int.c	Mon Jul 14 21:14:22 2003
@@ -1941,6 +1941,13 @@
   LWORD(esp) -= 4;
 }
 
+void fake_call_to(int cs, int ip)
+{
+  fake_call(REG(cs), LWORD(eip));
+  REG(cs) = cs;
+  REG(eip) = ip;
+}
+
 void fake_pusha(void)
 {
 #ifdef X86_EMULATOR
--- src/dosext/dpmi/dpmi.c	Sun Jun 15 19:43:23 2003
+++ src/dosext/dpmi/dpmi.c	Mon Jul 14 21:15:13 2003
@@ -1581,15 +1581,6 @@
       REG(ds) = rmreg->ds;
       REG(fs) = rmreg->fs;
       REG(gs) = rmreg->gs;
-      if (_LWORD(eax)==0x0300) {
-        if (_LO(bx)==0x21)
-          D_printf("DPMI: int 0x21 fn %04x\n",LWORD(eax));
-	REG(cs) = ((us *) 0)[(_LO(bx) << 1) + 1];
-	REG(eip) = ((us *) 0)[_LO(bx) << 1];
-      } else {
-	REG(cs) = rmreg->cs;
-	REG(eip) = (long) rmreg->ip;
-      }
       if (!(rmreg->sp==0)) {
 	REG(ss) = rmreg->ss;
 	REG(esp) = (long) rmreg->sp;
@@ -1606,36 +1597,29 @@
       if (tmp) E_MPROT_STACK(tmp_ssp);
 #endif
       LWORD(esp) -= 2 * (_LWORD(ecx));
-      if (_LWORD(eax)==0x0301)
-	       LWORD(esp) -= 4;
-      else {
-	LWORD(esp) -= 6;
-#ifdef X86_EMULATOR
-	tmp_ssp = rm_ssp+rm_sp;
-	tmp = E_MUNPROT_STACK(tmp_ssp);
-#endif
-	pushw(rm_ssp, rm_sp, LWORD(eflags));
-#ifdef X86_EMULATOR
-	if (tmp) E_MPROT_STACK(tmp_ssp);
-#endif
-	REG(eflags) &= ~(IF|TF);
+      in_dpmi_dos_int=1;
+      REG(cs) = DPMI_SEG;
+      LWORD(eip) = DPMI_OFF + HLT_OFF(DPMI_return_from_realmode);
+      switch (_LWORD(eax)) {
+        case 0x0300:
+          if (_LO(bx)==0x21)
+            D_printf("DPMI: int 0x21 fn %04x\n",LWORD(eax));
+	  do_int(_LO(bx));
+	  break;
+        case 0x0301:
+	  fake_call_to(rmreg->cs, rmreg->ip);
+	  break;
+        case 0x0302:
+	  fake_int_to(rmreg->cs, rmreg->ip);
+	  break;
       }
+
 /* --------------------------------------------------- 0x300:
      RM |  FC90C   |
 	| dpmi_seg |
 	|  flags   |
 	| cx words |
    --------------------------------------------------- */
-#ifdef X86_EMULATOR
-      tmp_ssp = rm_ssp+rm_sp;
-      tmp = E_MUNPROT_STACK(tmp_ssp);
-#endif
-      pushw(rm_ssp, rm_sp, DPMI_SEG);
-      pushw(rm_ssp, rm_sp, DPMI_OFF + HLT_OFF(DPMI_return_from_realmode));
-#ifdef X86_EMULATOR
-      if (tmp) E_MPROT_STACK(tmp_ssp);
-#endif
-      in_dpmi_dos_int=1;
     }
 #ifdef SHOWREGS
     if (debug_level('e')==0) {
--- src/include/int.h	Mon Jul 14 21:15:01 2003
+++ src/include/int.h	Mon Jul 14 21:15:09 2003
@@ -20,6 +20,7 @@
 void fake_int(int, int);
 void fake_int_to(int cs, int ip);
 void fake_call(int, int);
+void fake_call_to(int cs, int ip);
 void fake_pusha(void);
 void setup_interrupts(void);
 void version_init(void);

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: experimental LFN support for redirected drives
@ 2003-07-13 19:59 Stas Sergeev
  2003-07-13 19:34 ` Bart Oldeman
  0 siblings, 1 reply; 5+ messages in thread
From: Stas Sergeev @ 2003-07-13 19:59 UTC (permalink / raw)
  To: linux-msdos

Hello.

Bart Oldeman wrote:
> I put a patch up
Hmm, just wondering, what are those DPMI
changes are intended for?
According to DPMI specs:
---
However, there are three real mode software
interrupts that a DPMI host will always reflect to a 
protected mode handler, if one is installed:

      Int 1CH - ROM BIOS timer tick interrupt
      Int 23H - DOS Ctrl+C interrupt
      Int 24H - DOS critical error interrupt
---

Why are you adding a 0x21 here? Isnt it a direct
violation of a specs?

Another hunk to dpmi.c also looks very hackish.
What was the idea?


^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: experimental LFN support for redirected drives
  2003-07-13 19:59 Stas Sergeev
@ 2003-07-13 19:34 ` Bart Oldeman
  0 siblings, 0 replies; 5+ messages in thread
From: Bart Oldeman @ 2003-07-13 19:34 UTC (permalink / raw)
  To: linux-msdos

On Sun, 13 Jul 2003, Stas Sergeev wrote:

> Hmm, just wondering, what are those DPMI
> changes are intended for?

the reason for

    if (config.lfn && (LWORD(eax) & 0xff00) == 0x7100 &&
        (REG(cs) == ((us *) 0)[(0x21 << 1) + 1]) &&
	(REG(eip) == ((us *) 0)[0x21 << 1])) {
      REG(cs) = BIOSSEG;
      REG(eip) = INT_OFF(0x21);
    }

is a problem with this piece of code:

      if (_LWORD(eax)==0x0300) {
        if (_LO(bx)==0x21)
          D_printf("DPMI: int 0x21 fn %04x\n",LWORD(eax));
	REG(cs) = ((us *) 0)[(_LO(bx) << 1) + 1];
	REG(eip) = ((us *) 0)[_LO(bx) << 1];
      } else {

INT 21 now just executes the DOS int21 and never reaches the DOSEMU
revectored int21 code. I don't know if it's safe to transfer to
f000:_BL*0x10 for every interrupt. Maybe you do?

> According to DPMI specs:
> ---
> However, there are three real mode software
> interrupts that a DPMI host will always reflect to a
> protected mode handler, if one is installed:
>
>       Int 1CH - ROM BIOS timer tick interrupt
>       Int 23H - DOS Ctrl+C interrupt
>       Int 24H - DOS critical error interrupt
> ---
>
> Why are you adding a 0x21 here? Isnt it a direct
> violation of a specs?

that was a wrong try which I forgot to remove.

Bart


^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, other threads:[~2003-07-14 18:07 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2003-07-13 15:09 experimental LFN support for redirected drives Bart Oldeman
2003-07-13 19:59 Stas Sergeev
2003-07-13 19:34 ` Bart Oldeman
2003-07-14 17:29 Stas Sergeev
2003-07-14 18:07 ` Bart Oldeman

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.