* dosemu 1.1.5.6 @ 2003-07-20 16:33 Bart Oldeman 2003-07-21 5:13 ` Grigory Batalov 2003-07-25 18:15 ` Eemeli Kantola 0 siblings, 2 replies; 10+ messages in thread From: Bart Oldeman @ 2003-07-20 16:33 UTC (permalink / raw) To: linux-msdos 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: dosemu 1.1.5.6 2003-07-20 16:33 dosemu 1.1.5.6 Bart Oldeman @ 2003-07-21 5:13 ` Grigory Batalov 2003-07-25 18:15 ` Eemeli Kantola 1 sibling, 0 replies; 10+ messages in thread From: Grigory Batalov @ 2003-07-21 5:13 UTC (permalink / raw) To: linux-msdos 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). ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: dosemu 1.1.5.6 2003-07-20 16:33 dosemu 1.1.5.6 Bart Oldeman 2003-07-21 5:13 ` Grigory Batalov @ 2003-07-25 18:15 ` Eemeli Kantola 2003-08-22 23:10 ` dosemu 1.1.5.7 (was Re: dosemu 1.1.5.6) Bart Oldeman 1 sibling, 1 reply; 10+ messages in thread From: Eemeli Kantola @ 2003-07-25 18:15 UTC (permalink / raw) To: linux-msdos 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* dosemu 1.1.5.7 (was Re: dosemu 1.1.5.6) 2003-07-25 18:15 ` Eemeli Kantola @ 2003-08-22 23:10 ` Bart Oldeman 2003-08-23 7:21 ` Eemeli Kantola 2003-08-23 17:58 ` Ryan Underwood 0 siblings, 2 replies; 10+ messages in thread From: Bart Oldeman @ 2003-08-22 23:10 UTC (permalink / raw) To: Eemeli Kantola; +Cc: linux-msdos 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: dosemu 1.1.5.7 (was Re: dosemu 1.1.5.6) 2003-08-22 23:10 ` dosemu 1.1.5.7 (was Re: dosemu 1.1.5.6) Bart Oldeman @ 2003-08-23 7:21 ` Eemeli Kantola 2003-08-23 17:58 ` Ryan Underwood 1 sibling, 0 replies; 10+ messages in thread From: Eemeli Kantola @ 2003-08-23 7:21 UTC (permalink / raw) To: linux-msdos 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: dosemu 1.1.5.7 (was Re: dosemu 1.1.5.6) 2003-08-22 23:10 ` dosemu 1.1.5.7 (was Re: dosemu 1.1.5.6) Bart Oldeman 2003-08-23 7:21 ` Eemeli Kantola @ 2003-08-23 17:58 ` Ryan Underwood 2003-08-23 19:47 ` Bart Oldeman 1 sibling, 1 reply; 10+ messages in thread From: Ryan Underwood @ 2003-08-23 17:58 UTC (permalink / raw) To: linux-msdos 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: dosemu 1.1.5.7 (was Re: dosemu 1.1.5.6) 2003-08-23 17:58 ` Ryan Underwood @ 2003-08-23 19:47 ` Bart Oldeman 2003-08-23 21:59 ` Ryan Underwood 0 siblings, 1 reply; 10+ messages in thread From: Bart Oldeman @ 2003-08-23 19:47 UTC (permalink / raw) To: Ryan Underwood; +Cc: linux-msdos 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: dosemu 1.1.5.7 (was Re: dosemu 1.1.5.6) 2003-08-23 19:47 ` Bart Oldeman @ 2003-08-23 21:59 ` Ryan Underwood 2003-08-23 22:17 ` Bart Oldeman 0 siblings, 1 reply; 10+ messages in thread From: Ryan Underwood @ 2003-08-23 21:59 UTC (permalink / raw) To: linux-msdos 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: dosemu 1.1.5.7 (was Re: dosemu 1.1.5.6) 2003-08-23 21:59 ` Ryan Underwood @ 2003-08-23 22:17 ` Bart Oldeman 2003-08-23 22:36 ` Ryan Underwood 0 siblings, 1 reply; 10+ messages in thread From: Bart Oldeman @ 2003-08-23 22:17 UTC (permalink / raw) To: linux-msdos 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: dosemu 1.1.5.7 (was Re: dosemu 1.1.5.6) 2003-08-23 22:17 ` Bart Oldeman @ 2003-08-23 22:36 ` Ryan Underwood 0 siblings, 0 replies; 10+ messages in thread From: Ryan Underwood @ 2003-08-23 22:36 UTC (permalink / raw) To: linux-msdos 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2003-08-23 22:36 UTC | newest] Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2003-07-20 16:33 dosemu 1.1.5.6 Bart Oldeman 2003-07-21 5:13 ` Grigory Batalov 2003-07-25 18:15 ` Eemeli Kantola 2003-08-22 23:10 ` dosemu 1.1.5.7 (was Re: dosemu 1.1.5.6) Bart Oldeman 2003-08-23 7:21 ` Eemeli Kantola 2003-08-23 17:58 ` Ryan Underwood 2003-08-23 19:47 ` Bart Oldeman 2003-08-23 21:59 ` Ryan Underwood 2003-08-23 22:17 ` Bart Oldeman 2003-08-23 22:36 ` Ryan Underwood
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.