Re: dosemu 1.1.5.6

Re: dosemu 1.1.5.6

[Stas Sergeev]

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

Hello.

Grigory Batalov wrote:
> FYI, LD_ASSUME_KERNEL=2.2.5 doesn't work for me.
LD_ASSUME_KERNEL is a temporary solution
that was intended to be removed as soon as
the proper fix is found.
Unfortunately the side-effect is that people
are no longer interested in testing the potential
fixes - they are quite fine with LD_ASSUME_KERNEL
and I don't see how this can be resolved without
backing out the LD_ASSUME_KERNEL thing but this
is also not good before there is a tested fix:(

> Without LD_ASSUME_KERNEL it works. I use kernel 2.4.20
> and glibc-2.2.6 from ALTLinux distribution (www.altlinux.com).
Is there any chance for ALTLinux to get upgraded
to NPTL so that you can test the patches?

The potential fix I am talking about is attached.
If anyone have a broken DPMI due to NPTL without
an LD_ASSUME_KERNEL thing, please test.

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

--- src/arch/linux/async/sigsegv.c	Sat Jun  7 12:10:16 2003
+++ src/arch/linux/async/sigsegv.c	Thu Jul 17 20:52:08 2003
@@ -324,16 +324,21 @@
 {
  /*
   * FIRST thing to do - to avoid being trapped into int0x11
-  * forever, we must clear AC before doing anything else!
-  * Clear also ID for some reasons?
+  * forever, we must restore the eflags.
+  * Also restore the %fs and %gs for compatibility with NPTL.
   */
- __asm__ __volatile__ (" \
-	pushfl\n \
-	popl	%%eax\n \
-	andl	%0,%%eax\n \
-	pushl	%%eax\n \
-	popfl" \
-	: : "i"(~(AC|ID)) : "%eax");
+  if (in_dpmi && !in_vm86 && context.cs != UCODESEL) {
+    __asm__ __volatile__ (" \
+	pushl	%0\n \
+	popfl\n \
+	movw	%1, %%fs\n \
+	movw	%2, %%gs\n \
+	" \
+	: :
+	"m"(emu_stack_frame->eflags),
+	"m"(emu_stack_frame->fs),
+	"m"(emu_stack_frame->gs));
+  }
 
   fault_cnt++;
 
--- src/dosext/dpmi/dpmi.c	Wed Jul 16 21:54:22 2003
+++ src/dosext/dpmi/dpmi.c	Thu Jul 17 20:15:45 2003
@@ -142,8 +142,8 @@
 unsigned short DPMI_SEL = 0;
 
 struct sigcontext_struct dpmi_stack_frame[DPMI_MAX_CLIENTS]; /* used to store the dpmi client registers */
-static struct sigcontext_struct _emu_stack_frame;  /* used to store emulator registers */
-static struct sigcontext_struct *emu_stack_frame = &_emu_stack_frame;
+struct sigcontext_struct _emu_stack_frame;  /* used to store emulator registers */
+struct sigcontext_struct *emu_stack_frame = &_emu_stack_frame;
 
 #define CHECK_SELECTOR(x) \
 { if (!ValidAndUsedSelector(x) || SystemSelector(x)) { \
--- src/dosext/dpmi/dpmi.h	Wed Jul 16 21:54:20 2003
+++ src/dosext/dpmi/dpmi.h	Thu Jul 17 20:16:34 2003
@@ -142,6 +142,7 @@
 extern INTDESC Interrupt_Table[0x100];
 extern SEGDESC Segments[];
 extern struct sigcontext_struct dpmi_stack_frame[DPMI_MAX_CLIENTS];
+extern struct sigcontext_struct *emu_stack_frame;
 /* used to store the dpmi client registers */
 extern RealModeCallBack mouseCallBack; /* user\'s mouse routine */
 extern char *ldt_buffer;

Re: dosemu 1.1.5.6

[Grigory Batalov]

On Fri, 15 Aug 2003 18:43:55 +0400
Stas Sergeev <stsp@aknet.ru> wrote:

> > Without LD_ASSUME_KERNEL it works. I use kernel 2.4.20
> > and glibc-2.2.6 from ALTLinux distribution (www.altlinux.com).

> Is there any chance for ALTLinux to get upgraded
> to NPTL so that you can test the patches?

  Not sure about ALT Linux, but I can build kernel myself.
  (Or it was about glibc?)
  What is NPTL, BTW, and how to enable it?

> The potential fix I am talking about is attached.
> If anyone have a broken DPMI due to NPTL without
> an LD_ASSUME_KERNEL thing, please test.

  I didn't found such bug report at sourceforge,
  so can you describe me a testcase? I'll be glad
  to check it.

Re: dosemu 1.1.5.6

[Stas Sergeev]

Hello.

Grigory Batalov wrote:
> So I have to rebuild theese RPM's myself or just take
> their patches. I plan this to Saturday/Sunday.
That didn't happen and now is not
necessary anymore.
Finally the patch was tested:
https://sourceforge.net/tracker/?func=detail&atid=457447&aid=795147&group_id=49784
Thanks anyway for trying.

Re: dosemu 1.1.5.6

[Grigory Batalov]

On Tue, 26 Aug 2003 20:40:30 +0400
Stas Sergeev <stsp@aknet.ru> wrote:

> > So I have to rebuild theese RPM's myself or just take
> > their patches. I plan this to Saturday/Sunday.

> That didn't happen and now is not
> necessary anymore.
> Finally the patch was tested:
> https://sourceforge.net/tracker/?func=detail&atid=457447&aid=795147&group_id=49784
> Thanks anyway for trying.

  Sorry, I haven't succeeded.
  That patches (kernel's) rejects each other!

  Good that now you have a reliable test platform.

Re: dosemu 1.1.5.6

[Stas Sergeev]

Hello.

>> Is there any chance for ALTLinux to get upgraded to
>> NPTL so that you can test the patches?
> Not sure about ALT Linux, but I can build kernel myself. 
> (Or it was about glibc?)
I am afraid it is about both.

> What is NPTL, BTW, and how to enable it?
Not easy, unless you have RedHat9, where it
is enabled by default (hence the problems).
You have to install an RH-patched kernel, like
"kernel-2.4.21-20.1.2024.2.1.nptl RPM for i686"
and the RH-patched glibc >= 2.3.1-7.
Then you can do
getconf GNU_LIBPTHREAD_VERSION
and it will answer "NPTL" instead of the usual
"LinuxThreads".
Then you just start dosemu and it should crash
on any DPMI app, but not if you are using its
startup script which now disables NPTL with
that LD_ASSUME_KERNEL trick.

> I didn't found such bug report at sourceforge,
Here it is:
https://sourceforge.net/tracker/index.php?func=detail&aid=770746&group_id=49784&atid=457447
That guy provided me with an access to his RH
system, but he put there only one DPMI testcase
which he wrote himself: that program only switches
to prot.mode and does nothing. With that my patch
dosemu doesn't crash on that prog, but as the prog
does nothing, this is not a sufficient testing.
And the guy himself got tired of patches and simply
upgraded from CVS :(

> so can you describe me a testcase?
Any DPMI program basically. FoxPro will do just
fine for example.

> I'll be glad to check it.
Let's see how easy will it be to turn your distro
to an NPTL-enabled one. I am afraid also some
other progs may stop working, so don't do that
unless you have a separate machine for testings
or RH9 distro handy.

Re: dosemu 1.1.5.6

[Grigory Batalov]

On Sat, 16 Aug 2003 12:09:15 +0400
Stas Sergeev <stsp@aknet.ru> wrote:

> > I'll be glad to check it.

> Let's see how easy will it be to turn your distro
> to an NPTL-enabled one. I am afraid also some
> other progs may stop working, so don't do that
> unless you have a separate machine for testings
> or RH9 distro handy.

  Not so easy as I wished =).
  RedHat RPM's crashed my system.
  So I have to rebuild theese RPM's myself or just take
  their patches. I plan this to Saturday/Sunday.

dosemu 1.1.5.6

[Bart Oldeman]

Hi,

I've put up a dosemu 1.1.5.6 for testing to fix some (but not all) of the
problems with 1.1.5.5.

for instance:
* compiles with --without-x
* lots of LFN fixes
* hogthreshold adjustments for the mouse

one thing you should be aware of is that the redirector (MFS,
lredir'ed drive) behaviour with respect to files on vfat partitions has
changed: instead of mangled short names such as
PROGR~6I
you now see the real short names (obtained using a special ioctl) such as
PROGRA~1
for "Program Files". On proper filesystems such as ext2 this behaviour
hasn't changed and there you'll keep seeing the mangled names with non-LFN
DOS utilities.

Performance on VFAT-lredired drives should have improved a bit too, since
the code now exploits the fact that stat() is case insensitive on VFAT.

Bart

Re: dosemu 1.1.5.6

[Grigory Batalov]

On Sun, 20 Jul 2003 17:33:01 +0100 (BST)
Bart Oldeman <bartoldeman@users.sourceforge.net> wrote:

> I've put up a dosemu 1.1.5.6 for testing to fix some (but not all) of the
> problems with 1.1.5.5.

FYI, LD_ASSUME_KERNEL=2.2.5 doesn't work for me.
It causes "dosemu.bin: error while loading shared libraries: libm.so.6: cannot open shared object file: No such file or directory".

And 'strace -Ff dosemu' says:

...
open("/lib/libm.so.6", O_RDONLY)        = 4
read(4, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\2406\0"..., 1024) = 1024
close(4)                                = 0
stat64("/lib", {st_mode=S_IFDIR|0755, st_size=4687, ...}) = 0
...

Without LD_ASSUME_KERNEL it works. I use kernel 2.4.20
and glibc-2.2.6 from ALTLinux distribution (www.altlinux.com).

Re: dosemu 1.1.5.6

[Eemeli Kantola]

Bart Oldeman wrote:
> Hi,
> 
> I've put up a dosemu 1.1.5.6 for testing to fix some (but not all) of the
> problems with 1.1.5.5.
[...]
> * lots of LFN fixes

This new patch spawned an evil problem regarding LFN and international 
characters: if I have a file/dir with a long name with intl chars in it, 
I can't access that (ie. File not found) anymore, even though it is seen 
in dir listing. The worst thing is that this is also the case with LFN 
support disabled. I tested with 1.1.5.5 too, and it doesn't have that bug.


Other than that, there seem to be several problems with file names 
containing international chars, which make them practically unusable. I 
tested both 1.1.5.5 and 1.1.5.6 with LFN and intl chars under dos 7.10 
command.com and 4dos 6.22. Nobody seems to have reported bugs on this, 
so here are some:

- I can't create files with intl chars in the name.

- Intl chars show up in names incorrectly.

If you under win9x or unix create a text file containing intl chars, 
they appear incorrectly under dos edit, for example. This has something 
to do with font differences between dos and windows/unix, but is anyway 
the "preferred" behavior. However, windows somehow converts chars in 
file names somehow that they look the same under dos and windows. Dosemu 
seems to know nothing about that: as an example, a file named "cliché" 
is shown as "clich<theta>" (where <theta> is a single greek theta) under 
dosemu.

Without LFN, dosemu just leaves out the international chars and mangles 
the name ("clich~bc"), which is fine as long as the files are 
accessible. I was able to live with these things in 1.1.5.5, but not 
1.1.5.6.


-Eemeli

-
To unsubscribe from this list: send the line "unsubscribe linux-msdos" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html