* 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.