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