dosemu 1.1.5.6

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

dosemu 1.1.5.7 (was Re: dosemu 1.1.5.6)

[Bart Oldeman]

On Fri, 25 Jul 2003, Eemeli Kantola wrote:

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

right so this problem surfaced in 1.1.5.6 since the vfat kernel driver
translates from codepage xxx (default=437) to codepage iso8859-1 and
1.1.5.6 (on VFAT) doesn't mangle short filenames.

Well it turned out that this easy approach (no mangling at all on
VFAT) wasn't feasible in all cases and that with the unicode
infrastructure already there in several places it was not that hard to
translate filenames from the UNIX to the DOS character set now.

In my testings (and Stas' for Cyrillic) it all works so I've put up
1.1.5.7 at http://www.dosemu.org/testing to ask for wider testing.

We'll try to fix the LD_ASSUME_KERNEL and RH 9 issues for 1.1.5.8.

Also in 1.1.5.7:
* should fix the attribute (color) problems reported by Bernhard Bialas
* DPMI was improved at several places; now it runs Windows 3.1 with
  os2win31.zip again.
* some smaller fixes

Bart

-
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

Re: dosemu 1.1.5.7 (was Re: dosemu 1.1.5.6)

[Eemeli Kantola]

Bart Oldeman wrote:
> On Fri, 25 Jul 2003, Eemeli Kantola wrote:
> 
> 
>>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.
> 
> 
> right so this problem surfaced in 1.1.5.6 since the vfat kernel driver
> translates from codepage xxx (default=437) to codepage iso8859-1 and
> 1.1.5.6 (on VFAT) doesn't mangle short filenames.
> 
> Well it turned out that this easy approach (no mangling at all on
> VFAT) wasn't feasible in all cases and that with the unicode
> infrastructure already there in several places it was not that hard to
> translate filenames from the UNIX to the DOS character set now.
> 
> In my testings (and Stas' for Cyrillic) it all works so I've put up
> 1.1.5.7 at http://www.dosemu.org/testing to ask for wider testing.

Thanks, that seems to have fixed about every filename problem I had!

-
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

Re: dosemu 1.1.5.7 (was Re: dosemu 1.1.5.6)

[Ryan Underwood]

Hi Bart,

I updated my unofficial dosemu-devel debian package for 1.1.5.7.
http://home.icequake.net/~nemesis/debian/binary/dosemu-devel_1.1.5.7-1_i386.deb

Also, the following code in Makefile.conf presents a problem:
ifeq (0,${MAKELEVEL})
  export abs_top_builddir:=$(shell cd $(top_builddir) && pwd -P)
  SUBDIR := $(subst $(abs_top_builddir)/src/,,$(shell pwd -P))
else
endif

The problem is that when debian/rules install target calls the install
target for DOSEMU, MAKELEVEL is 1, not zero, so abs_top_builddir is not
set, and Makefile.main's install target tries to rm -rf /tmp (!).

This is only a problem when using the debian build system (which also
uses make) -- a standalone build doesn't do it.

Changing ifeq (1,${MAKELEVEL}) works for debuild, but is a hack.

Ryan


On Sat, Aug 23, 2003 at 12:10:54AM +0100, Bart Oldeman wrote:
> On Fri, 25 Jul 2003, Eemeli Kantola wrote:
> 
> > 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.
> 
> right so this problem surfaced in 1.1.5.6 since the vfat kernel driver
> translates from codepage xxx (default=437) to codepage iso8859-1 and
> 1.1.5.6 (on VFAT) doesn't mangle short filenames.
> 
> Well it turned out that this easy approach (no mangling at all on
> VFAT) wasn't feasible in all cases and that with the unicode
> infrastructure already there in several places it was not that hard to
> translate filenames from the UNIX to the DOS character set now.
> 
> In my testings (and Stas' for Cyrillic) it all works so I've put up
> 1.1.5.7 at http://www.dosemu.org/testing to ask for wider testing.
> 
> We'll try to fix the LD_ASSUME_KERNEL and RH 9 issues for 1.1.5.8.
> 
> Also in 1.1.5.7:
> * should fix the attribute (color) problems reported by Bernhard Bialas
> * DPMI was improved at several places; now it runs Windows 3.1 with
>   os2win31.zip again.
> * some smaller fixes
> 
> Bart
> 
> -
> 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
> 

-- 
Ryan Underwood, <nemesis at icequake.net>, icq=10317253
-
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

Re: dosemu 1.1.5.7 (was Re: dosemu 1.1.5.6)

[Bart Oldeman]

On Sat, 23 Aug 2003, Ryan Underwood wrote:

> The problem is that when debian/rules install target calls the install
> target for DOSEMU, MAKELEVEL is 1, not zero, so abs_top_builddir is not
> set, and Makefile.main's install target tries to rm -rf /tmp (!).

Looks like Debian fixed that:
http://cvs.debian.org/debian-installer/build/Makefile
http://cvs.debian.org/debian-installer/build/Makefile.diff?r1=1.154&r2=1.155

> This is only a problem when using the debian build system (which also
> uses make) -- a standalone build doesn't do it.
>
> Changing ifeq (1,${MAKELEVEL}) works for debuild, but is a hack.

using
	unset MAKELEVEL; make
in the (Debian) top level makefile should work too.

This particular trick is documented in the GNU make documentation so
I would like to avoid to change Makefile.conf.in.

Bart

Re: dosemu 1.1.5.7 (was Re: dosemu 1.1.5.6)

[Ryan Underwood]

Hi Bart,

On Sat, Aug 23, 2003 at 08:47:33PM +0100, Bart Oldeman wrote:
> On Sat, 23 Aug 2003, Ryan Underwood wrote:
> 
> > The problem is that when debian/rules install target calls the install
> > target for DOSEMU, MAKELEVEL is 1, not zero, so abs_top_builddir is not
> > set, and Makefile.main's install target tries to rm -rf /tmp (!).
> 
> Looks like Debian fixed that:
> http://cvs.debian.org/debian-installer/build/Makefile
> http://cvs.debian.org/debian-installer/build/Makefile.diff?r1=1.154&r2=1.155

Well, that particular patch looks like it is for the debian-installer
package which is not related to DOSEMU.  However, I can use the same
trick in my build script.  I'm mainly curious why this only started
happening in 1.1.5.7 -- I built 1.1.5.6 and previous with no
modifications or extra pain needed.

> This particular trick is documented in the GNU make documentation so
> I would like to avoid to change Makefile.conf.in.

Ok, I will do that.

-- 
Ryan Underwood, <nemesis at icequake.net>, icq=10317253

Re: dosemu 1.1.5.7 (was Re: dosemu 1.1.5.6)

[Bart Oldeman]

On Sat, 23 Aug 2003, Ryan Underwood wrote:

> On Sat, Aug 23, 2003 at 08:47:33PM +0100, Bart Oldeman wrote:
> > On Sat, 23 Aug 2003, Ryan Underwood wrote:
> >
> > > The problem is that when debian/rules install target calls the install
> > > target for DOSEMU, MAKELEVEL is 1, not zero, so abs_top_builddir is not
> > > set, and Makefile.main's install target tries to rm -rf /tmp (!).
> >
> > Looks like Debian fixed that:
> > http://cvs.debian.org/debian-installer/build/Makefile
> > http://cvs.debian.org/debian-installer/build/Makefile.diff?r1=1.154&r2=1.155
>
> Well, that particular patch looks like it is for the debian-installer
> package which is not related to DOSEMU.  However, I can use the same
> trick in my build script.  I'm mainly curious why this only started
> happening in 1.1.5.7 -- I built 1.1.5.6 and previous with no
> modifications or extra pain needed.

well the trick avoids using $(shell ... pwd) in Makefiles for each
recursive invocation of "make". $(shell) is fairly expensive; by reducing
the number of it to exactly one (instead of ~100 in 1.1.5.6) it was
possible to reduce the time to "make" a (nearly) built tree
significantly, on one PC by about 10 seconds from 15 to less than 5; and
Clarence Dang has seen even greater differences.

For a user who compiles her/himself this doesn't matter that much but for
a developer who often makes a small change and then recompiles it saves a
lot of waiting.

Bart

Re: dosemu 1.1.5.7 (was Re: dosemu 1.1.5.6)

[Ryan Underwood]

Hi Bart,

On Sat, Aug 23, 2003 at 11:17:14PM +0100, Bart Oldeman wrote:
> >
> > Well, that particular patch looks like it is for the debian-installer
> > package which is not related to DOSEMU.  However, I can use the same
> > trick in my build script.  I'm mainly curious why this only started
> > happening in 1.1.5.7 -- I built 1.1.5.6 and previous with no
> > modifications or extra pain needed.
> 
> well the trick avoids using $(shell ... pwd) in Makefiles for each
> recursive invocation of "make". $(shell) is fairly expensive; by reducing
> the number of it to exactly one (instead of ~100 in 1.1.5.6) it was
> possible to reduce the time to "make" a (nearly) built tree
> significantly, on one PC by about 10 seconds from 15 to less than 5; and
> Clarence Dang has seen even greater differences.
> 
> For a user who compiles her/himself this doesn't matter that much but for
> a developer who often makes a small change and then recompiles it saves a
> lot of waiting.

Sounds reasonable to me, I've worked around it in my build script.

See ya,

-- 
Ryan Underwood, <nemesis at icequake.net>, icq=10317253

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.

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

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 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]

[-- 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;