Re: FOSDEM talk next week
Hi everyone, thanks very much for the feedback. It was more than I expected, so I have plenty of material to work with -- most examples will just need to be condensed into bullet points. All FOSDEM talks are recorded, see https://video.fosdem.org/ Cheers, Bart -- To unsubscribe from this list: send the line "unsubscribe linux-msdos" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
FOSDEM talk next week
Hi, I'll be talking about DOSEMU and FreeDOS at FOSDEM next week: https://fosdem.org/2018/schedule/event/dosemu_and_freedos_past_present_future/ There may not be so many people on this list any more but I'd thought I'd reach out. If you use DOSEMU in any useful or cool setting please let me know and I can mention it as an example (you can do so privately too, then I can make it an anonymous example). As far as development goes, for me mostly life with two small children took over, but as he wrote Stas Sergeev has continued with dosemu2 so that is where all the action happens. Bart -- To unsubscribe from this list: send the line "unsubscribe linux-msdos" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Character sets
Hi, On Jan 22, 2008 9:16 AM, Andrew Bird (Sphere Systems) [EMAIL PROTECTED] wrote: I've a quick question about the character set support in dosemu 1.2.2. I have previously rebuilt an rpm from source rpm on a Centos 3 system and everything worked fine, all of the box drawing characters were available when necessary. Now I take the same rpm source file, rebuild it on a Centos 5.1 system, and applications are not able to use the box drawing characters, they are using characters like 'A' with a little horizontal colon on the top. I'm guessing that Centos 5.1 uses UTF-8 by default but Centos 3 did not. DOSEMU 1.2.2 did not support UTF-8. You can try DOSEMU 1.4.0, or iso-8859-1 instead of UTF-8, or xdosemu. Bart - To unsubscribe from this list: send the line unsubscribe linux-msdos in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 64-bit compile? - SOLVED
On Nov 15, 2007 7:16 AM, Bryan J. Smith [EMAIL PROTECTED] wrote: Hence why I wrote a brief blog article here: 'What is x86-64? Long Mode memory model ...' http://thebs413.blogspot.com/2005/10/what-is-x86-64-long-mode-memory-model.html One thing to correct, otherwise it looks fine: 'Long Mode also offers a 48-bit (256TiB) Flat address model by using the 16-bit segment register as bits 32-47 to the 32-bit offset register of bits 0-31. This is the new memory model that programs and libraries may use.' No, segment registers are large ignored in long mode! What happens is that you have 64-bit registers RAX, RBX, RCX etc., and using those you can address 48-bits (bits 48-63 are not used). In fact there is a 2^47 byte sized positive user address space from 0 to 2^47-1 and a 2^47 sized negative kernel address space from 2^64-2^47 to 2^64-1. As for segment registers, only fs and gs are used, and each have a 64-bit base address associated to them; the bits of fs and gs themselves are independent of bits 32-47 of the final address. In a nutshell, 48-bit (PAE 52-bit) addressed Long Mode is focused on being 32-bit (PAE 36-bit) i486 TLB (i686 PAE) compatible. But there is no reason why it can't support i386 Virtual86 modes either. The patch allows Virtual86 programs to run on a Long Mode kernel just as fast as they do on i486 or i686 PAE kernels. Long mode does not support running i386 Virtual86 modes. That's how the chip works. In fact the chip has three modes: real legacy long legacy (what we used to simply call protected mode) has three submodes: 16-bit protected, 32-bit protected, and Virtual86 long also has three submodes: 16-bit protected, 32-bit protected, and 64-bit protected: note that V86 is missing! It is easy to switch between submodes, but harder to switch between modes; interrupt handling in particular is different. So the referenced kernel patch needs to shut off long mode, disable paging, enter legacy mode, re-enable paging, and then enter virtual-86 mode. Everytime an interrupt comes in, it needs to do the reverse -- nothing goes as easy as automatically resetting a flag as with a legacy mode (32-bit) kernel. Indeed the similarities between 52-bit and 36-bit PAE make it possible to not having to convert page tables though. Hope that clarifies some bits, Bart - To unsubscribe from this list: send the line unsubscribe linux-msdos in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: cifs 1.50 and dosemu 1.4 great combination
On 10/12/07, Alain M. [EMAIL PROTECTED] wrote: Sorry if I may seam a little dumb, but some time ago Bart said that lock did NOT work... and I googled about cifs and could not really understand the details. Locking works, but not 100%. The problem is that DOS has 5 different locking modes (compat, deny read, deny write, deny all, and deny none), but POSIX only 3 (none, read, and write). So somehow DOSEMU maps 5 to 3 and tries to be reasonable, but it is a heuristic. It may work, or it may not work for a particular application in a particular situation. And there's a chain: DOSEMU -1 Linux fs = cifs -2 samba or Windows server -1 translates DOS locks to POSIX locks (lredir'ed drive). -2 (may) do the reverse (mounted drive using the Linux kernel cifs module). smbfs used to do nothing at all with POSIX locks at -2 so it was broken. cifs now does it better (possibly as well as two DOSEMU's sharing files on an ext3 filesystem by now); if the samba server implements POSIX extensions there isn't even a lock translation anymore for step 2. Having DOSEMU talk directly to the samba server could be 100% reliable but a bit hard to setup (setup networking in DOSEMU, and install a DOS samba client in it). Bart - To unsubscribe from this list: send the line unsubscribe linux-msdos in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: CTRL+Fn and ALT+Fn mappings
On 10/3/07, Paolo Gaggini [EMAIL PROTECTED] wrote: Thank you for the answer, but: 1) the problem affects only the linux console (without X I mean) In that case you should be able to use the raw keyboard ($_rawkeyboard = (1) or the -k switch). Unless DOSEMU is run remotely (or even from inside mc), in which case there is a lot more to configure. Bart - To unsubscribe from this list: send the line unsubscribe linux-msdos in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Some further questions about booting
On 6/18/07, Jan Willem Stumpel [EMAIL PROTECTED] wrote: 1) create a $HOME/.dosemurc file with a line in it $_hdimage = $HOME/olddos 2) go to $HOME/.dosemu/drives and do ln -nsf $HOME/olddos c 3) go to $HOME/.dosemu and do mv drive_c drive_c.orig ln -nsf $HOME/olddos drive_c (BTW which of these 3 methods would be the best?) It doesn't really matter in the end. 2) is what dosemu -install does, since it avoids needing to edit the user's .dosemurc. But what I do not understand is how the original C: drive (just after a fresh install), namely $HOME/.dosemu/drive_c, could work. It does not contain the .sys files that a DOS boot disk should have. Just AUTOEXEC and CONFIG. So how can it boot? It's magic :) If dosemu can't find a kernel in C:\ it'll fall back on the kernel.sys that is installed in $DOSEMU_LIB_DIR/drive_z, loads it into DOS memory and executes it. Bart - To unsubscribe from this list: send the line unsubscribe linux-msdos in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Drives directory
On 6/17/07, Jan Willem Stumpel [EMAIL PROTECTED] wrote: After a fresh install of dosemu 1.4 (I used the Debian package) there is a directory ~/.dosemu/drives which contains lrwxrwxrwx 1 jws users 25 2007-06-17 10:54 c - /home/jws/.dosemu/drive_c lrwxrwxrwx 1 jws users 23 2007-06-17 10:54 d - /usr/lib/dosemu/drive_z (I suppose in the .rpm version the link d would point at /usr/share/dosemu/drive_z). Yes What do these links do? After starting dosemu, the D: drive is $HOME, not /usr/lib/dosemu/drive_z (which is Z:). It must be the AUTOEXEC.BAT in ~/.dosemu/drive_c that does this, but why? And how does it work? CONFIG.SYS cannot see drive Z: yet (a DOS limitation: DOS just assigns C:, D:, etc) so it temporarily uses drive D: instead to access the relevant files (ems.sys, lredir.exe, etc). Then the lredir command is used in config.sys and autoexec.bat to set the drives to what you see after starting dosemu. D: is set to $HOME because it was there in 1.2.x too. Bart - To unsubscribe from this list: send the line unsubscribe linux-msdos in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: DOSEMU vga font
On 6/2/07, Frank Cox [EMAIL PROTECTED] wrote: Once again the spam filtering on this mailing list appears to have eaten my post. I got your message twice actually. (Again, does anyone know how to go about getting my address whitelisted so this won't keep happening?) I don't think that's possible... but there is information on what is permitted and what not on http://vger.kernel.org/majordomo-info.html and http://vger.kernel.org/majordomo-taboos.txt It has never been clear to me how to get rid of this error and since it never affected or changed anything I haven't given it much thought. However, now that I'm playing with DOSEMU 1.4.0, it might be a good time to deal with this error and get rid of it. The message comes from the dosemu script (/usr/bin/dosemu). It's on my todo list for 1.4.1 to get rid of it, it's harmless, wrong by default, and at the wrong place. dosemu.bin can complain if it can't find the font though. Essentially, if you don't set $_X_font, or use the default setting, then a bitmap font is used; X fonts aren't necessary for that. If you set it to vga (as was the default in 1.2.1 and earlier), and vga is not available, then the message is relevant. However the script isn't smart enough to know all that. Bart - To unsubscribe from this list: send the line unsubscribe linux-msdos in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: umb's unavailable
On 5/30/07, Frank Cox [EMAIL PROTECTED] wrote: One more minor issue. This doesn't appear to be an actual problem, at least not for what I'm trying to run at the moment. However, when I first crank up dosemu, I get the message UMB's unavailable! dosemu XMS 3.0 driver installed. dosemu EMS 4.0 driver installed. This is using the stock config.sys file that comes with dosemu. So... who stole the UMB's? UMB's are not available until you load ems.sys. This is to allow the use of real DOS XMS drivers such as himem.sys which would otherwise complain that an XMS driver is already present. Change the first devicehigh to device to get rid of the message. Browse http://dosemu.svn.sourceforge.net/viewvc/dosemu/trunk/dist/ to see what config.sys and autoexec.bat will look like in the next version (you can use them with 1.4.0 too). Bart - To unsubscribe from this list: send the line unsubscribe linux-msdos in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Creating directories with pkunzip, rar, et. al.
On 5/7/07, Mike McCarty [EMAIL PROTECTED] wrote: How soon will this be folded into the standard release? it is already in the Subversion repository... as to when the next release is, I don't know. But there have been quite a few little post 1.4.0 fixes so perhaps 1.4.1 doesn't take very long. It all depends on time, I won't make any promises. Bart - To unsubscribe from this list: send the line unsubscribe linux-msdos in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: A dos character problem
On 4/24/07, Andrew Brooks [EMAIL PROTECTED] wrote: I too am struggling to get to grips with character mappings but am finding it very confusing! DOS program - dosemu mappings - screen mappings ($TERM, locale env vars, -T option, etc.) - terminal then on other screen clients there is also the corresponding $TERM, locale env vars, screen options - terminal character encodings, etc., plus the differences between gnome term vs xterm, ... True, there are lots of layers, and if only one is wrong things go strange. UTF-8 is nice in this respect because it cuts a few layers. Without UTF-8, but with iso-8859-1 we have: $_internal_char_set (e.g. cp437) character 179 (0xb3), is converted to Unicode 0x2502 (Box drawings light vertical) Try to convert 2502 to $_external_char_set (default: locale charmap). No match: check if $TERM supports the PC character set, if yes, fine, output the smpch terminfo setting, then character 179, then rmpch. If smpch is not available, check if $TERM supports the alternate (VT100) character set, if yes, fine, but use smacs and acsc to determine what to output. If neither smpch nor smacs are available, output an approximation (|) Now $TERM must accurately describe the terminal, and all should be fine, if that isn't true then man iso-8859-1 and mc will also often fail to display correctly. With UTF-8. the 2502 is unconditionally converted to UTF-8 \xe2\x94\x82, which is sent to the terminal without any $TERM involvement. Bart - To unsubscribe from this list: send the line unsubscribe linux-msdos in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Creating directories with pkunzip, rar, et. al.
On 5/7/07, Joe Ripley [EMAIL PROTECTED] wrote: The problem I have is, when pkunzip (in my case, pkunzip 2.50) is ran with the '-d' switch (to automatically create the original directory structure of the archive) it fails. ... The reason that PKUNZIP 'can't create' the files, is because the directories (BIN, DATA, etc.) don't have the execute bit set on them. ... Anyway, I'm running DOSEMU 1.3.5. I've tried both MS-DOS 6.22 and FreeDOS 1.0 and the problem exists in both. Is there some kind of umask setting that will control this behavior, or is it an internal DOSEMU problem? It's an internal DOSEMU problem, and an old one at that! The problem is that DOSEMU emulates the archive DOS attribute through the user x bit. Very few DOS programs attempt to set or reset the archive attribute on directories, but pkunzip 2.50 does. The same problem happens with dosemu 1.2.2 (which crashes unless you use the -3 option of pkunzip). I'm going to fix it in DOSEMU by ignoring set attribute requests on directories but there are other workarounds, e.g. by using INFO-ZIP (for DOS or Linux) or older versions of pkunzip. On a mounted FAT partition the problem should not happen either. Bart - To unsubscribe from this list: send the line unsubscribe linux-msdos in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Creating directories with pkunzip, rar, et. al.
On 5/7/07, Joe Ripley [EMAIL PROTECTED] wrote: On 5/7/07, Joe Ripley [EMAIL PROTECTED] wrote: Actually, I had some time to do some testing, and I found that it's not that pkunzip is attempting to set the archive attribute. When run with the debug messages turned on, pkunzip tries to create the directory with an attribute of 0x10 (i.e. a regular file) rather than 0x20 (a directory). No, first of all creating a directory does not involve any attributes, and secondly 0x10=directory, and 0x20=archive. What you see in a -D+dD log with LFN's enabled is something like this: INT21 (0) at 02a8:3478: AX=7139, BX=caf4, CX=, DX=caf4, DS=0c28, ES=0c28 LFN: doing LFN!, AX=7139 DL=f4 LFN: mkdir DOC (...) INT21 (0) at 02a8:344b: AX=7143, BX=ca01, CX=0020, DX=caf4, DS=0c28, ES=0c28 LFN: doing LFN!, AX=7143 DL=f4 LFN: attribute DOC 1 the CX=20 here is the new attribute (ie. archive) As a hack to fix it, all I did was add one line to the beginning of the set_dos_attr() function in mfs.c: if (S_ISDIR(mode)) attr = DIRECTORY; This is correct, since the read-only attribute must also be ignored. However, there is also some FAT code that does not need the clearance. So I committed a similar check but in a different place, get_unix_attr(): --- src/dosext/mfs/mfs.c(revision 1784) +++ src/dosext/mfs/mfs.c(revision 1785) @@ -608,6 +608,12 @@ #if 0 #define S_IWRITEA (S_IWUSR | S_IWGRP | S_IWOTH) #endif + /* Do not make directories read-only as this has completely different + semantics in DOS (mostly ignore) than in Unix. + Also do not reflect the archive bit as clearing the x bit as that + can cause inaccessible directories */ + if (S_ISDIR(mode) || (attr DIRECTORY)) +attr = DIRECTORY; mode = ~(S_IFDIR | S_IWRITE | S_IEXEC); if (attr DIRECTORY) mode |= S_IFDIR; - To unsubscribe from this list: send the line unsubscribe linux-msdos in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Vga detect problem
On 5/4/07, George Laskowsky [EMAIL PROTECTED] wrote: I have just installed dosemu 1.3.5 + freedos 1.0 succefully. Sound is perfect and I can play keen 4, hero quest and other games. But, when I try to play my first original game, Stonkeep, the following message apears: Stonkeep requires a VGA or Super VGA card. I've been playing with dosemu.conf parameters, but with out better results. Any ideas?... please... Please run with -D+vDd and post the contents of ~/.dosemu/boot.log It is probably an issue with the emulated VGA or BIOS. Bart - To unsubscribe from this list: send the line unsubscribe linux-msdos in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: new file owner and permissions
On 5/4/07, normalboy [EMAIL PROTECTED] wrote: when i create a new file in xdosemu, the new file is owned by root (group is root too) even when i'am running xdosemu as normal user. The xdosemu and dosemu binaries have NOT the SETUID root flag (+2). What can cause this behaviour? The files are on a FAT partition so they are forced root:root? Bart - To unsubscribe from this list: send the line unsubscribe linux-msdos in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[announce] DOSEMU 1.3.5 and DOSEMU-FreeDOS 1.0 tarballs
Hi, I uploaded a new developer's release of DOSEMU, see dosemu.org/bleeding, and also updated FreeDOS tarballs. I think, that apart from some documentation updates, binaries, and any last minute problems that come up, this is essentially DOSEMU 1.4.0. I encourage distributors who still use 1.2.2 to switch to this version. With respect to 1.3.4 there have not been very many changes, mainly bug fixes. Stas' new sound system is included as an optional non-default (for now) run-time option, and there have been quite a few cpuemu fixes. The x86-64 port now runs quite stable in my experience, but others may still find new issues. I also uploaded new FreeDOS tarballs, with a subset of FreeDOS 1.0. They can only be used with DOSEMU 1.3.4 or later. Enjoy, Bart Version 1.3.5 (2007-04-27) = * A new sound system is available, written by Stas Sergeev. It is for now an optional run-time option, $_sound=(2). * Lredir can now automatically find a new drive (Ryan Underwood, Stuart Axon). * CPUEMU fixes (many by Michael Karcher). This also means that DOSEMU now runs more stable on x86-64. * Other fixes, affecting printer handling, MMX/SSE FPU state preservation, DPMI, Linux console graphics PCI handling on x86-64, the position of . and .. in dir, UTF-8 multibyte input in terminals, SDL key handling, a double mouse cursor in Arachne in X, and make install. List of SourceForge tracker numbers with bugs that were closed: #1245033 --version flag for dosemu.bin is not described #1436788 DOSEMU 1.3.3 Problem with floating point #1602643 Regression in DosEmu 1.3.4 #1638135 int 21h, ax=6300 not translated currently #1644784 SR: Proposed Change to INSTALL file here #1678581 cpuemu JIT fails certain kinds of self-modifying code #1679675 P: cpuemu jit cpatch for stosw destroys EAX on 32 bit dosemu #1682575 P: cpuemu bug: sbb r16,rm16 acts on wrong register #1682620 P: cpuemu bug: single stepping push pushes wrong register #1683073 P: handle 16bit address overflow in string instructions. #1683190 P: Fix flags on rep cmps/scas with ECX=0 #1687296 P: Shift/rotate instructions in simulator wrong #1687298 P: Fix spurious crashes with linker: node busy #1691712 P: make lredir able to automatically choose next free drive II #1692149 P: Describe --version in man page (fix for 1245033) #1692299 P: Update howto - To unsubscribe from this list: send the line unsubscribe linux-msdos in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: xdosemu crash
On 4/28/07, Ondrej Krsko [EMAIL PROTECTED] wrote: I'm trying to run one older sw written in Clipper for MS-DOS in xdosemu. It works fine, but occasionaly it crashes - I did not find a specific procedure which causes the crashes. what is your DOSEMU version? After crash the following error appears: Error: cpu exception in dosemu code outside of VM86()! ... Exception was caused by insufficient privilege. I use Xubuntu 6.10. Do you know what can I do? Give the contents of ~/.dosemu/boot.log after a crash. Also try dosemu 1.3.5 and see if that still crashes. Bart - To unsubscribe from this list: send the line unsubscribe linux-msdos in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Slow dosemu printing
Hello,
the attached patch causes
$_lpt2=
to completely disable LPT2, independent of any $_port setting.
It also flushes every second. Let me know if it helps.
Bart
Index: src/base/dev/misc/lpt.c
===
--- src/base/dev/misc/lpt.c (revision 1716)
+++ src/base/dev/misc/lpt.c (working copy)
@@ -221,11 +221,11 @@
lpt[i].remaining = -1; /* mark not accessed yet */
if (lpt[i].dev)
lpt[i].fops = dev_pfops;
-else
+else if (lpt[i].prtcmd)
lpt[i].fops = pipe_pfops;
if (i = config.num_lpt) lpt[i].base_port = 0;
-if (lpt[i].base_port) {
+if (lpt[i].base_port != 0 lpt[i].fops.open) {
io_device.start_addr = lpt[i].base_port;
io_device.end_addr = lpt[i].base_port + 2;
port_register_handler(io_device, 0);
@@ -258,6 +258,8 @@
lpt[i].remaining--;
if (!lpt[i].remaining)
printer_close(i);
+ else if (lpt[i].file != NULL)
+ fflush(lpt[i].file);
}
}
}
Re: A dos character problem
Hi Lars, I'm not sure if the problem is in BRLTTY or in DOSEMU; everything on the DOSEMU side seems fine. You get ³ (SUPERSCRIPT THREE) if you do alt-179 in a Linux console since that's the code in iso-8859-1. However, in cp850 it's that vertical line so DOSEMU tries to translate it; the line program tries a few things to display it, and you did not see (or, rather, feel) it. You could try to set export TERM=linux-vt and run line and dosemu with that setting. It may make a difference. Bart - To unsubscribe from this list: send the line unsubscribe linux-msdos in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Unicode in dosemu under xterm
On 4/19/07, Grigory Batalov [EMAIL PROTECTED] wrote:
Hello!
I got a problem running dosemu in terminal (xterm): there is no Russian symbols.
Xdosemu works well. This is my settings:
$_external_char_set = utf8
One workaround is to leave this to default which takes the current
locale setting.
That does not solve flickering when you input non-ASCII though.
So I don't understand, why d1,84 became later symbol:3444 instead of
symbol:0444.
A bug in the UTF-8 code...
It's fixed in SVN rev 1736; you could also apply the attached instead.
Bart
Index: src/plugin/term/keyb_slang.c
===
--- src/plugin/term/keyb_slang.c (revision 1735)
+++ src/plugin/term/keyb_slang.c (revision 1736)
@@ -1274,6 +1274,8 @@
/* rough draft version don't stop here... */
result = charset_to_unicode(keyb_state.translate_state,
symbol, keyb_state.kbp, keyb_state.kbcount);
+ if (result != -1 result keyb_state.Keystr_Len)
+keyb_state.Keystr_Len = result;
k_printf(KBD: got %08x, result=%zx\n, symbol, result);
}
Index: src/plugin/translate/charsets/utf8.c
===
--- src/plugin/translate/charsets/utf8.c (revision 1735)
+++ src/plugin/translate/charsets/utf8.c (revision 1736)
@@ -47,7 +47,6 @@
goto bad_string;
}
if (len = bytes_desired) {
- result = ch;
for(i = 1; i bytes_desired; i++) {
ch = str[i];
if ((ch = 0x80) (ch = 0xBF)) {
Re: A dos character problem
Hi,
Ok, but it should not be displayed exactly as the normal vertical bar
|? It has to have it's own uniqe representation?
it's a line drawing character; the ASCII | is sometimes used as
approximation but does not extend far enough. Many DOS applications
(and also Linux ones such as mc) use it to draw boxes.
Is there other things to try?
Yes, run
dosemu -D+v
and send the contents of ~/.dosemu/boot.log
it contains the DOS to Linux character set translation table.
There could also be a problem with BRLTTY and the box drawing
characters... we may be able to work around that but first please
check the output of the program below (save as line.c, compile using
gcc -lncurses line.c -o line, run as ./line)
Bart
#include stdio.h
#include locale.h
#include langinfo.h
#include term.h
int main(void)
{
int i;
setlocale(LC_ALL, );
if (strcmp(nl_langinfo(CODESET), UTF-8) == 0) {
printf(Terminal supports UTF-8\n);
printf(Vertical bar: \xe2\x94\x82\n);
return 0;
}
setupterm((char *)0, 1, (int *)0);
if (enter_pc_charset_mode) {
printf(Terminal supports PC charset mode\n);
printf(Vertical bar: );
printf(%s, enter_pc_charset_mode);
putchar(0xb3);
if (exit_pc_charset_mode)
printf(%s, exit_pc_charset_mode);
printf(\n);
}
if (acs_chars) {
printf(Terminal supports alternate charset mode\n);
printf(Vertical bar: );
if (enter_alt_charset_mode)
printf(%s, enter_alt_charset_mode);
for (i = 0; acs_chars[i]; i += 2) {
if (acs_chars[i] == 'x') {
putchar(acs_chars[i+1]);
break;
}
}
if (exit_alt_charset_mode)
printf(%s, exit_alt_charset_mode);
printf(\n);
}
return 0;
}
-
To unsubscribe from this list: send the line unsubscribe linux-msdos in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: A dos character problem
On 4/13/07, Lars Bjørndal [EMAIL PROTECTED] wrote: With all versions I've tried of Dosemu, I have problem with some special characters. Now, I also tried the current svn version with the same result. I'm a Norwegian using charset iso8859-1 and no-latin1 keyboard layout on a Fedora core 6 system, and without GUI. The relevant settings in dosemu.conf that's changed, is: $_rawkeyboard = (1) $_internal_char_set = cp850 Try to make sure you are *really* using iso8859-1. Fedora has everything UTF-8 by default so it's easy to miss out on something. On the Linux console, for non-suid DOSEMU you'd need a) locale settings without utf8 (output of locale) b) the console in 8-bit mode (using unicode_stop) c) a good font. I sometimes do setfont default8x16 to get at least all cp437 characters. Although I just checked that LatArCyrHeb* at least works for your character. everything UTF-8 should work too. Try not to mess with $_external_char_set for now. Character : ³ (0263, 179, 0xb3 charset: eight-bit-graphic (8-bit graphic char (0xa0..0xff)) code point: 179 0xb3 (or alt-179) produces a vertical bar in most DOS codepages (incl 437, 850, ..) Bart - To unsubscribe from this list: send the line unsubscribe linux-msdos in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: FM sound
On 3/20/07, Jan Willem Stumpel [EMAIL PROTECTED] wrote: Somebody called my attention to the fact that in the latest SVN versions of the dosemu source code, there is revision 1718: a) Does this mean that dosemu is now again being developed cooperatively and peacefully? Are all conflicts resolved? Yes, and no. There have recently been patches by Michael Karcher (very good work to fix some nasty cpuemu bugs which is good for the x86-64 port) and also by Stuart Axon. When I had more time to work on DOSEMU last October and November, Reinhard Karcher was also following closely and provided good feedback. I haven't heard from Stas after September last year, but I think 1.3.4 has addressed all or most of his concerns. But I don't know why, Stas and I have argued a lot in the past, it's probably a personality clash (on both sides) since with most other people it usually doesn't go that way. I just decided to incorporate Stas' work... cautiously as a run-time option, to make it easier to maintain than as a seperate patch, and hopefully it will have the kinks worked out with a little time, and the old system can be deleted. b) This new sound support does work on my system in some programs but not in others. For instance, in Wolf3d the music stops (and dosemu hangs) after a few seconds with the message: ERROR: PCM: ERROR: buffer on stream 2 exhausted (Adlib) How to cure this? An earlier application of the Sergeev sound patch on my system did not have this problem. I use MS-DOS 6, (well, out of laziness), not freedos. I don't know. I can give it a try later, though I am quite busy these days. Stas' new sound system has been applied pretty much unmodified so it is a bit strange. Bart - To unsubscribe from this list: send the line unsubscribe linux-msdos in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re:
On 3/8/07, Ruthard Baudach [EMAIL PROTECTED] wrote: I'd like to use dosemu 1.3.4 SVN from 6.2.2007 to run a proprietary medical program on an AMD64. dosemu compiles and installs. Freedos works great. My program crashes. It runs perfectly well under the same SVN Version compiled and installed on a mobielSempron. dosemu -D+a produces 11 MByte output I cannot use. Has anyone an idea except to wait an hope that sometimes an SVN-checkout will solve the problem? Updating from SVN actually might solve the problem now, since there have been a few fixes (thanks to Michael Karcher) and a few more are pending within a few days. Bart - To unsubscribe from this list: send the line unsubscribe linux-msdos in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Keyboard problem with xfce4
On 2/26/07, Jan Willem Stumpel [EMAIL PROTECTED] wrote: I am trying out the lightweight desktop system xfce4 (version 4.3.99). In xfce4 you can make launcher icons on the desktop. When I do this for launching dosemu (version 1.3.3.1) it's hard to see what is 1.3.3.1without a date because it must be some CVS or SVN snapshot. Can you try again with 1.3.4 or a current SVN snapshot? There were a few keyboard fixes around October last year. Bart - To unsubscribe from this list: send the line unsubscribe linux-msdos in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: DOSEMU 1.3.4 and $_term_char_set
On 12/21/06, Stéfano Schotten [EMAIL PROTECTED] wrote: As we don't have the $_term_char_set variable anymore, I´m having problem to run a Cobol system where before my system was like: $_term_char_set=ibm $_internal_char_set=cp437 $_external_char_set=cp437 $_external_char_set=cp437 is almost always wrong. It's easiest to leave it at the default., but you could set it explicitly to your local set, ie. iso8859-1. Also, with your locale, make sure your console is not in utf-8 mode (unicode_stop). Bart - To unsubscribe from this list: send the line unsubscribe linux-msdos in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[announce] DOSEMU 1.3.4
Hi, DOSEMU 1.3.4 is out, see http://dosemu.sourceforge.net/bleeding/ I hope this is almost version 1.4.0; FreeDOS still needs to be updated to 1.0 but that's about it as far as features are concerned. There have been a few too many changes to be comfortable about that at this stage, so any user testing is welcome to find regressions. Bart NEWS: * For a first time boot with FreeDOS, DOSEMU now boots without any user interaction, and presents a welcome screen. Drive Z: is now a read-only drive with all the DOSEMU and FreeDOS support files. * Clarified the copyrights and replaced some code with unclear origins. The disclaimer acceptance has been weakened. * Added native 64-bit support for x86-64, which, similarly to the 32-bit version, uses CPU emulation for V86 mode, and runs DPMI code natively. Most of the code is now 64-bit clean but a few cases may not work yet. * The CPUEMU simulator is now a runtime option, activated via $_cpuemu=vm86sim, or $_cpuemu=fullsim. Improved correctness of CPUEMU. * Added a $_cdrom option for runtime configuration of the CD-ROM device. * Added an internal *CDEX style CD-ROM driver, activated using LREDIR, for use with CD-ROMs that are mounted in Linux. The default autoexec.bat uses this to set drive E: to a CD-ROM. * Implemented support for Unicode fonts for $_X_font, so you can for instance use the univga font or $_X_font=-Misc-Fixed-Medium-R-SemiCondensed--13-120-75-75-C-60-ISO10646-1 * Use $_lpt1, $_lpt2, and $_lpt3 for printer configuration. * The SDL plugin now supports text copy and paste, and X fonts. * It is now possible to point $_vbootfloppy, $_floppy_a etc. to directories and boot from them. * Improved real time clock support with a periodic IRQ generator. * Improved PCI emulation on the console, with $_pci=(auto). * Improved the internal XMS driver. * Various DPMI and VGAEMU fixes. * The dosemu script is compatible with the minimal shell dash. * You can now directly see and manipulate DOS file attributes on Lredir'ed Linux-mounted (V)FAT partitions, when using recent 2.6 kernels. * DOSEMU's stack is no longer marked executable which may improve security. - To unsubscribe from this list: send the line unsubscribe linux-msdos in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [announce] DOSEMU 1.3.4
On 11/18/06, Jan Willem Stumpel [EMAIL PROTECTED] wrote: Bart Oldeman schreef: Hi, DOSEMU 1.3.4 is out, see http://dosemu.sourceforge.net/bleeding/ Does this new version include Stas Sergeev's sound patch? No, I had the impression that his patch was still very much in development though looking at it now it seems to have most things sorted out. If not, does it allow the patch to be applied? No, although the reasons are quite trivial (2005 - 2006 change etc). I am not sure what Stas is up to these days (if he has abandoned dosemu completely including his sound patch or is just away); you could try emailing him directly. Bart - To unsubscribe from this list: send the line unsubscribe linux-msdos in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: compiling the cvs source
On Thu, 8 Sep 2005, Andrzej Kaczmarczyk wrote: Hi, I tried to compile the today (20050908) cvs snapshot, got following error, what can I do about it? should be fixed now, in CVS, subject to a few hours delay. You can set experimental on in compiletime-settings to work around it. Bart - To unsubscribe from this list: send the line unsubscribe linux-msdos in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: dosemu
On Wed, 31 Aug 2005, Barrein, Karsten (Autostadt) wrote: i'd like to start a dos programm made by myself under suse linux 8.0. how can i start this programm by a cron job? like: dosemu -run /.../programname.exe ? You'll have to use '-dumb' to force a dumb terminal, and perhaps also set TERM=none. It's a bit like the dosemu -dumb dir listing example in the manual page. Bart - To unsubscribe from this list: send the line unsubscribe linux-msdos in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: cp852 font
On Wed, 24 Aug 2005, Andrzej Kaczmarczyk wrote: there is no Keyb (which isn't necessary anyway, since it only deal with keyboard to font mapping, which is done by dosemu, correctly), there is DISPLAY (whose docs says something about modecom.exe which isn't present, but I assume that docs are just old and not updated (hint, hint, hint), and there is mode. I believe when DISPLAY was released there was just modecon, and later Eric Auer improved MODE to have MODE CON behave like the old MODECON, but the DISPLAY docs don't know that yet. It's a FreeDOS issue. mode co80,25 - no errors just comment : Could only set 37, not 25 mode co80,43 - Using VGA 350 lines. Could only set 37 not 43 mode co80,50 - Using VGA 400 lines. Could only set 37 not 50 my gut feeling tells me that it is all about termcap files which define how the text console should look like. However this is 700kB sized conf file, and I don't have a slightest idea whats going on there. Basically if you run dosemu in a terminal (and the Linux console is one), it just takes rows and columns as a given and does not try to change those. I presume you're using fbdev with 800x600 resolution to fit 100x37. Unless you use vesafb (needs to set it at boot time). You can try to use fbset to set 1024x768, and then use stty cols 80 rows 43 in Linux to limit columns and rows. DOSEMU could also do that itself (what stty does) but it's usually a bit of a waste of screen space; DOS modes assume 80x25, and so what you'd then see is that only the left upper half of the screen is used. There are two alternatives which give you graphics on the console: 1. direct hardware access: see Stas' mail and README. You need root though, either suid-root or sudo access to dosemu.bin. 2. framebuffer console via SDL. This is safer but slower, how much slower depends. This works if you are in the video group, then dosemu -S should do the trick. Bart - To unsubscribe from this list: send the line unsubscribe linux-msdos in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: DOSEMU CVS Crash With Kernel 2.6.12
On Thu, 14 Jul 2005, T.P. Reitzel wrote: Is anyone working on the source of this crash? From the latest CVS, it still exists on my Slackware 10.1 PC. This error is printed on the console when I attempt to run dosemu from X or the console: ERROR: cpu exception in dosemu code outside of VM86()! trapno: 0x0e errorcode: 0x0006 cr2: 0x4035a000 eip: 0x400a43ab esp: 0xbfcbd090 eflags: 0x00210206 cs: 0x0073 ds: 0x007b es: 0x007b ss: 0x007b Page fault: write instruction to linear address: 0x4035a000 CPU was in user mode Exception was caused by non-available page My previous debug output is still valid. It would be helpful if you recompile using ./default-configure -d make and reproduce this report as it will give a more complete backtrace, and it would be even more helpful if you'd use the sourceforge bug tracker to report your bug. Bart - To unsubscribe from this list: send the line unsubscribe linux-msdos in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Dosemu 1.3.2 and linux 2.6.7 headers
On Wed, 13 Jul 2005, Stas Sergeev wrote: Maybe add the proper headers to the dosemu source tree as we did before? The question is which headers? Many headers include some linux/*.h file but it seems that only sys/pci.h is problematic. It's easy to get rid of that #include by simply putting some extra #define's in our src/include/pci.h. But then is it just sys/pci.h? I mean sys/pci.h is undocumented as far as I can see (neither info libc nor man pages seem to mention it), but the same is true for sys/soundcard.h, sys/vt.h, sys/kd.h and perhaps some others. All goes to show that grepping headers isn't a good way to obtain documentation... The LSB contains a really clean header system. But that's *too* clean for dosemu, as things like vm86 and *mntent functions are missing, Bart - To unsubscribe from this list: send the line unsubscribe linux-msdos in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Dosemu 1.3.2 and linux 2.6.7 headers
On Tue, 12 Jul 2005, Hufnus wrote: On Tue, 12 Jul 2005 12:07:21 -0800 Hufnus [EMAIL PROTECTED] wrote: Anybody runing 1.3.2 or trying with Linux 2.6 So I tried to compile with Linux 2.6.7 headers, but the make gets some obsolete warnings and then fails with many parse errors in /usr/include/linux/mod_devicetable.h related to symbols like __u32 etc Now, if I relink 'ln -sf linux-2.4.31 linux' it still complains about using -malign-? is obsolete to use -falign-? but it builds fine. I know I am using Skackware's default symbolic link /usr/include/linux - /usr/src/linux-2.6.7/include/linux !!! This is not its default symbolic link. You must have created it yourself, manually. My question is what should I do Delete the link? yes! Copy that directory over to /usr/include/linux? no! or what??? I've go a deja vu feeling here, this has been discussed before. You need to install Slackware's kernel-headers package (it's in the d series, over here for instance: ftp://ftp.slackware.com/pub/slackware/slackware-current/slackware/d/kernel-headers-2.4.31-i386-1.tgz They contain sanitized 2.4.31 headers that were used to compile glibc, and that is what user space (incl dosemu) sometimes sees indirectly. Just don't mess with /usr/include/linux, unless you really know what you are doing and are willing to recompile glibc. Bart - To unsubscribe from this list: send the line unsubscribe linux-msdos in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Dosemu 1.3.2 and linux 2.6.7 headers
On Tue, 12 Jul 2005, Hufnus wrote: Looking at those kernel headers vs the kernel distribution ones, I guess that should work. Unfortunately I am usually in a higher kernel than Slackware-current is, so always get in trouble. Yes, but the deal is: that should not matter! In Slackware you should install kernel-headers-2.4.31 no matter what (independent of!) the kernel you happen to be running at any time, whether 2.2.22, 2.4.31, 2.4.32, 2.6.7 or 2.6.12. At least as long as you don't recompile glibc. Looking at /usr/include/linux headers, I think there is a bug in linux/pci.h. It #includes linux/mod_devicetable.h, at the top and outside of an #ifdef __KERNEL__ which is located further down, where #include linux/types.h is also present. It seems to me that inside the #ifdef __KERNEL__ is where it should be placed. No, those are not the /usr/include/linux headers, the ones you are talking about are those in include/linux in the kernel source code. Maybe the kernel guys will pick that change up, if it carries no other implications ... they won't, as they know that include/linux headers are broken beyond repair for user space inclusion. see here: http://lkml.org/lkml/2005/5/3/173 Bart - To unsubscribe from this list: send the line unsubscribe linux-msdos in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 2.6.12-rc1 breaks dosemu
On Sat, 26 Mar 2005, Arjan van de Ven wrote: There is one more improbable thing I can think of: comcom. This is dosemu's built-in command.com and uses some very tricky code (coopthreads), which certainly does not work any more with address space randomization. It's deprecated but was still present in 1.2.2, and Debian packages still used it with dosemu 1.2.1. The fix for that one is easy: replace your command.com with a real DOS command.com (e.g. FreeDOS freecom). #define STACK_GRAN_SHIFT 17 /* 128K address space granularity */ #define STACK_GRAN(1U STACK_GRAN_SHIFT) #define STACK_TOP 0xc000U #define STACK_BOTTOM 0xa000U #define STACK_TOP_PADDING STACK_GRAN #define STACK_SLOTS ((STACK_TOP-STACK_BOTTOM) STACK_GRAN_SHIFT) #define roundup_stacksize(size) ((size + STACK_GRAN - 1) (-((int)STACK_GRAN))) that certainly isn't boding well for things ok this thing is evil. In some private correspondence with Arnd it turned out that this code was indeed the culprit for him. Fortunately it's easy to avoid -- when you do as I wrote above it becomes dead code, and dosemu works just fine (confirmed). In default dosemu 1.2.x setups it's also dead code; it's just Debian that chose to continue using it. Fear not. The offending code has since been removed, in development versions of dosemu, if for no other reason than that except for the original author (Hans Lermen) nobody understood it. Hope that clears things up. Bart - To unsubscribe from this list: send the line unsubscribe linux-msdos in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 2.6.12-rc1 breaks dosemu
On Sat, 26 Mar 2005, Arjan van de Ven wrote: On Fri, 2005-03-25 at 23:54 +0100, Arnd Bergmann wrote: On Freedag 25 Mrz 2005 20:14, Arjan van de Ven wrote: the randomisation patches came in a series of 8 patches (where several were general infrastructure); could you try to disable the individual randomisations one at a time to see which one causes this effect? It's caused by top-of-stack-randomization.patch. eip: 0x69ee esp: 0xbfdbffcc eflags: 0x00010246 hmm interesting. Can you check if at the time of the crash, the esp is actually inside the stack vma? If it's not, I wonder what dosemu does to get its stack pointer outside the vma... (and on which side of the vma it is) To Arnd: Another thing you should probably do is to build dosemu with debug information, and then look into ~/.dosemu/boot.log after it crashes. That will give you the contents of /proc/self/maps, a gdb backtrace and various other goodies. I've checked it myself but can't reproduce, neither with plain dosemu 1.2.2 nor with current CVS. Bart - To unsubscribe from this list: send the line unsubscribe linux-msdos in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: usage with libgpm
On Sun, 13 Mar 2005, Ryan Underwood wrote: So what's the best way to set things up so that mouse works in both console graphics mode (i.e. $_mouse + $_mouse_dev set) as well as in terminal mode using libgpm without changing the conffile in between invocations? basically dosemu has 6 mouse frontends: 1. X 2. xterm 3. via gpm 4. SDL 5. console graphics (internal mouse driver) 6. console graphics (serial mouse with DOS mouse driver) $_mouse_dev and $_mouse *only* affect the mouse in console graphics mode (5 and 6). If these settings change the behaviour of dosemu in terminal mode then that's a bug. Bart - To unsubscribe from this list: send the line unsubscribe linux-msdos in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: usage with libgpm
Just to elaborate on what Stas said On Thu, 10 Mar 2005, Ryan Underwood wrote: When dosemu is built with libgpm support, what $_mouse and $_mouse_dev should be used? these settings are irrelevant when libgpm is used. libgpm is only used for the console in terminal mode, that is, when dosemu is as useful as when you run it in an xterm (no graphics, just text mode). This is sometimes useful because VC switching is much smoother if you run dosemu in terminal mode than in console graphics, and it doesn't sacrifice security either. But since 99% of all Linux desktop users seem to use X 100% of the time it is not really so important I think. When they are commented out, no DOS program can see the mouse. $_mouse = (microsoft) and $_mouse_dev = /dev/gpmdata works, but I thought this was not supposed to be necessary when libgpm is used. It is necessary. The long story is that dosemu sends an ioctl(console_fd, KDSETMODE, KD_GRAPHICS); because once the VBIOS does all its stuff all the Linux console management goes out of the window and gpm can't trust it anymore. For 2.6 kernels it would perhaps be simpler to use the mouse event device instead of all this manual business. It doesn't quite help that by the standard of dead that was used in the threads here, gpm is very much dead by now. libgpm can also be binary incompatible from one distro to another one which is another PITA for the binaries on dosemu.org. Bart - To unsubscribe from this list: send the line unsubscribe linux-msdos in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Catastrophic X graphics slowdown going from 1.0.2.1 to 1.2.2.0
On Tue, 16 Nov 2004, jegunn wrote: Thanks. I tried this a little while before I got your reply; the performance is *very* sensitive to the setting; 3 is more-or-less OK, but better with zero. I was using 1 before with 1.0.2.1. Did the priority code change between these versions? yes, certainly. You may even want to try 1.2.1 and see how that behaves, since there were a few changes between 1.2.1 and 1.2.2 that can be regressions in certain cases (we'll have to look at this more closely). There's a big difference between hogthreshold 1 and 2, then to 3 4 5 etc it goes more gradually. With 0 you pretty much have dosemu using 100% CPU all the time; with say 10 it will still sleep most of the time at the DOS prompt for instance. Bart - To unsubscribe from this list: send the line unsubscribe linux-msdos in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Catastrophic X graphics slowdown going from 1.0.2.1 to 1.2.2.0
On Wed, 17 Nov 2004, jegunn wrote: in .dosemurc. So the memory size is recognized, but the vesamode line is not. Has the syntax changed? The documentation has not. No, it's a typo. in dosemu's etc/global.conf replace foreach $yyy ( , $X_vesamode) by foreach $yyy ( , $_X_vesamode) recompile and I hope you are all set then. Bart - To unsubscribe from this list: send the line unsubscribe linux-msdos in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Catastrophic X graphics slowdown going from 1.0.2.1 to 1.2.2.0
Thanks much, Bart. I am running from the binary distribution, so I took the chicken's way out and changed dosemu.users to read the fixed global.conf file. Ok, that's fine, it just overrides the builtin one then. quilla:SDSSPrettypicsxdosemu [1] 3541 quilla:SDSSPrettypicsERROR: Unable to open console to evaluate the keyboard map. Please specify your keyboard map explicitly via the $_layout option ERROR: Unable to open console to evaluate the keyboard map. Please specify your keyboard map explicitly via the $_layout option I uncommented the $_layout = auto in .dosemurc to no avail, but $_layout = us fixed it. $_layout=auto does not work if you don't have any read permissions to the Linux console. Nothing to do with global.conf I see. This is a known problem (apart from the fact that for remote X sessions it is wrong to query the console on the remote machine): in the next version (it's in CVS now) $_layout=auto will query the X server about the keyboard layout so in many cases it will no longer be necessary to explicitly specify $_layout=us etc. Bart - To unsubscribe from this list: send the line unsubscribe linux-msdos in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Floppy disk very slow
Hi Bernhard, I have discovered the following strange behavior of the floppy disk: -accessing from hard disk to floppy (via f: a: command) takes approx. 10 sec - then, the dir command takes from 1-5 minutes to list the directory content Also no chance to start any program from the disk. Under Linux the behavior is normal: an ls give in approx 1 sec the content of the floppy. My question: have some other people made a simillar experience? The test are done with dosemu 1.2.2 and 1.3.1 Linux System is SuSE 9.1 (kernel 2.6.5 (with some patches)),on a AMD Duron system. It has to do with kernel 2.6, and the way dosemu accesses the floppy. I had not used a floppy at all for 2 months or so (so I tend to forget these problems, almost forgetting that floppies still exist...) but trying it again with kernel 2.6.9 it seems the problem is still there. There's a bug in SF somewhere that tells about it. Maybe has this something to do with the fact that the floppy is mounted via subfs ? I don't think so. If I actually have the floppy mounted at the same time in Linux (like mount -t msdos /dev/fd0 /floppy) dosemu reads the floppy much faster. Then you need to be careful not to write to the floppy via both methods though: either dosemu or the mounted directory can be written to but not both at the same time or you'll face filesystem corruption. lredir a: linux\fs/floppy is another (safe) alternative. Bart - To unsubscribe from this list: send the line unsubscribe linux-msdos in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: PICs on Linux
Hello, The printer driver and DOSEMU's port passing cannot share the physical printer port. Therefore you need to disable the printer driver if you want to use DOSEMU's port passing, either temporarily or permanently. Yes, and remember to use 'fast' unless you want to do debugging/tracing: $_ports = fast range 0x378 0x37a means pass through 0x378-0x37a in fast mode. You have to start DOSEMU as root or use sudo in order for port/irq passing to work. It's still a bit tricky. This is the nature of direct hardware access under Linux, the jail around you (protected mode OS) needs to be partially broken down. There are security issues to deal with, etc etc. -- this is why we can never let this happen out of the box for a normal (non-root) user. This is not unique to Linux, under Windows XP there are even people trying to make a buck selling direct hardware access. http://www.zeecube.com/ParPort2004.htm we don't ask for $19.95 but you have to pay in other ways (trickier setup) so to speak. However: Linux 2.4 and 2.6 kernels provide a ppdev device driver that allows raw parallel port access via /dev/parports/0 etc. DOSEMU could virtualize the parallel port hardware and re-route it through that device thereby avoiding the root issue. I don't have any parallel port hardware to play with but it could be a nice little project to implement in DOSEMU one day. Speed shouldn't be such a big deal: according to http://www.ussg.iu.edu/hypermail/linux/kernel/0303.0/0978.html you can only do about 30 inb's and outb's per second anyway. Bart - To unsubscribe from this list: send the line unsubscribe linux-msdos in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: PICs on Linux
However: Linux 2.4 and 2.6 kernels provide a ppdev device driver that allows raw parallel port access via /dev/parports/0 etc. DOSEMU could virtualize the parallel port hardware and re-route it through that device thereby avoiding the root issue. I don't have any parallel port hardware to play with but it could be a nice little project to implement in DOSEMU one day. Wine has this already: http://cvs.winehq.com/cvsweb/wine/dlls/winedos/ppdev.c?rev=1.3 it may even be fairly easy to port this. Bart - To unsubscribe from this list: send the line unsubscribe linux-msdos in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Long file names and Alt-Gr characters
On Tue, 19 Oct 2004, Claudia Neumann wrote: Am Dienstag, 19. Oktober 2004 11:54 schrieben Sie: Can you try some explicit $_layout settings? There seems to be a $_layout = de without dead keys and a $_layout = de_latin1 which uses dead keys. I had $_layout = de_latin1 and now tried it with $_layout = de. It's the same. Should I download from CVS? I doubt that will help. Perhaps it may help with the other problem but I'd still like to know where the problem really is any case. Does the keyboard problem only occur in terminals or also in xdosemu? Does the key work in Linux just before you start dosemu? Can you provide a log (-D+k), just pressing a problematic key, and then kill dosemu from another terminal? and retry? The gdb backtrace will be much more useful then. Okay, attached last 500 lines of boot.log That's a very nasty crash in malloc(). Can you try again using electric fence? Most Linux distributions provide this package, it could be named libefence or electric-fence or similar. Then run LD_PRELOAD=/usr/lib/libefence.so dosemu.bin -D+Dd Bart - To unsubscribe from this list: send the line unsubscribe linux-msdos in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Long file names and Alt-Gr characters
On Mon, 18 Oct 2004, Claudia Neumann wrote:
Again I am having problems with some special characters: with dosemu-1.2.2.0
and dosemu-1.3.1 I can´t get a backslash \ or other characters like [, ],
{,}, and @ with cp850. It seems all characters which use Alt-Gr in German
keyboard layout don't work.
Can you try some explicit $_layout settings?
There seems to be a $_layout = de without dead keys and a $_layout =
de_latin1 which uses dead keys.
Interestingly it works on an other computer with
dosemu-1.2.2.0. I suspect it is again some slang mystery. Therefore I
attached my config.log. Which slang library should I use for compiling?
The slang is ok, probably. There were problems with utf8-enabled slang
(which you reported a long time ago) and the configure script checks for
those.
Only in the CVS any slang is ok now, as DOSEMU was fixed to deal with UTF8
terminals. A nice thing about UTF8 is that it allows us to show all the
funny DOS text symbols (pseudo graphics), including the card suits and
smileys even in terminal mode if the right font is loaded.
But dosemu crashes when it tries do delete the java directories with the long
java file names. I attached the last lines of the boot.log.
It is the same with dosemu-1.2.2.0 as with dosemu-1.3.1. Once it even killed
X.
This looks like an MFS bug. Can you try to compile with
make distclean
./default-configure -d
make
and retry? The gdb backtrace will be much more useful then.
Bart
-
To unsubscribe from this list: send the line unsubscribe linux-msdos in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Real text in xdosemu
On Wed, 29 Sep 2004, Jan Willem Stumpel wrote:
It is strange .. copying and pasting to and from xdosemu (text
programs only, of course) *does* works fine in 1.3. And it works
irrespective of the font used, and whether the text window is
resizable or not!
I had problems myself with KDE 3.2.3: after you selected by dragging the
mouse it would be cleared as soon as I released the mouse button. That's
fixed now and committed to the CVS. The fix for 1.2.2 is below in case
anyone is interested.
Why selections are highlighted in some programs and not in others,
I have no idea. Even within the same program there are
differences. For instance in Turbo C, selections are highlighted
in the main edit screen, but not in the help screens. But
selections can be taken from both of them.
True, I'll have a look at that later.
Bart
--- src/env/video/X.c 4 Jul 2004 05:39:55 - 1.4.2.10
+++ src/env/video/X.c 14 Oct 2004 09:34:04 -
@@ -453,9 +453,16 @@
static int sel_start_row = -1, sel_end_row = -1, sel_start_col, sel_end_col;
static unsigned short *sel_start = NULL, *sel_end = NULL;
static u_char *sel_text = NULL;
-static Atom compound_text_atom = None;
-static Atom utf8_text_atom = None;
-static Atom text_atom = None;
+enum {
+ TARGETS_ATOM,
+ TIMESTAMP_ATOM,
+ COMPOUND_TARGET,
+ UTF8_TARGET,
+ TEXT_TARGET,
+ STRING_TARGET,
+ NUM_TARGETS
+};
+static Atom targets[NUM_TARGETS];
static Boolean doing_selection = FALSE, visible_selection = FALSE;
#endif
@@ -844,9 +851,12 @@
}
#if CONFIG_X_SELECTION
/* Get atom for COMPOUND_TEXT/UTF8/TEXT type. */
- compound_text_atom = XInternAtom(display, COMPOUND_TEXT, False);
- utf8_text_atom = XInternAtom(display, UTF8_STRING, False);
- text_atom = XInternAtom(display, TEXT, False);
+ targets[TARGETS_ATOM] = XInternAtom(display, TARGETS, False);
+ targets[TIMESTAMP_ATOM] = XInternAtom(display, TIMESTAMP, False);
+ targets[COMPOUND_TARGET] = XInternAtom(display, COMPOUND_TEXT, False);
+ targets[UTF8_TARGET] = XInternAtom(display, UTF8_STRING, False);
+ targets[TEXT_TARGET] = XInternAtom(display, TEXT, False);
+ targets[STRING_TARGET] = XA_STRING;
#endif
/* Delete-Window-Message black magic copied from xloadimage. */
proto_atom = XInternAtom(display, WM_PROTOCOLS, False);
@@ -4094,8 +4104,20 @@
(unsigned long) requestor);
e.xselection.property = None;
}
- else if ((target == XA_STRING) || (target == compound_text_atom) ||
-(target == utf8_text_atom) || (target == text_atom)) {
+ else if (target == targets[TARGETS_ATOM]) {
+ X_printf(X: selection: TARGETS\n);
+ XChangeProperty(display, requestor, property, XA_ATOM, 32,
+ PropModeReplace, (char *)targets, NUM_TARGETS);
+ }
+ else if (target == targets[TIMESTAMP_ATOM]) {
+ X_printf(X: timestamp atom\n);
+ XChangeProperty(display, requestor, property, XA_INTEGER, 32,
+ PropModeReplace, (char *)e.xselection.time, 1);
+ }
+ else if (target == targets[STRING_TARGET] ||
+ target == targets[COMPOUND_TARGET] ||
+ target == targets[UTF8_TARGET] ||
+ target == targets[TEXT_TARGET]) {
X_printf(X: selection: %s\n,sel_text);
e.xselection.target = target;
XChangeProperty(display, requestor, property, target, 8,
PropModeReplace,
@@ -4107,8 +4129,9 @@
else
{
e.xselection.property = None;
- X_printf(X: Window 0x%lx requested unknown selection format %ld\n,
- (unsigned long) requestor, (unsigned long) target);
+ X_printf(X: Window 0x%lx requested unknown selection format %ld %s\n,
+ (unsigned long) requestor, (unsigned long) target,
+XGetAtomName(display, target));
}
XSendEvent(display, requestor, False, 0, e);
}
-
To unsubscribe from this list: send the line unsubscribe linux-msdos in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Symantec Ghost Console Client under Dosemu
On Thu, 30 Sep 2004, Stas Sergeev wrote:
So it was removed. Not really, just disabled in
global.conf, AFAICS. You can easily get it back
with a trivial hack in global.conf (or even
without any hacks at all).
you don't even need global.conf -- global.conf syntax also works in
dosemu.conf.
$_hdimage =
disk {wholedisk /dev/hda}
in dosemu.conf (or root's ~/.dosemurc if root runs dosemu) does
the job. Though I had to use $_vbootfloppy (a floppy image) to boot, since
DOSEMU doesn't like GRUB in the MBR (tries to go to protected mode
itself).
It was never really removed, just never supported in the new dosemu.conf
syntax (Feb 98, 0.97.2, over two years before I was involved). But right
now there isn't much of a reason anymore; as it used to be dosemu was
suid-root by default and any user could get the wholedisk (depending on
dosemu.users), now it solely depends on the permissions of /dev/hda.
So I'm not opposed to it, just too lazy to add the support to dosemu.conf
;)
Bart
-
To unsubscribe from this list: send the line unsubscribe linux-msdos in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: unix command
On Tue, 21 Sep 2004, Claudia Neumann wrote: This fails because unix changes to /home/user It doesn't change to there, it simply isn't aware of the current DOS directory. /home/user would be the directory you were in when you started DOSEMU. and leaves unzip looking for file.zip in /home/user instead of /home/user/dosemu/freedos/tmp. How can I change the behavior of the command unix so that it remains in the current DOSemu directory? unix would have to do some funny tricks, borrowing from MFS to translate the DOS dirname to a Linux dirname. It would not always work either -- how about unix ls c:foo d:bar Because unix can't parse DOS command lines reliably. That said, there exists a workaround, uchdir. uchdir /home/user/dosemu/freedos/tmp unix unzip file.zip does the job. Bart - To unsubscribe from this list: send the line unsubscribe linux-msdos in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Dosemu and SCSI
On Mon, 13 Sep 2004, Lars Bjørndal wrote: Are there somebody out there who can help me? The aspi.sys loads, but the cdtools.exe does not find the scsi CD-ROM drive. [EMAIL PROTECTED] (Lars Bjørndal) writes: I have problems with scsi! I want to access my CD-RW, and that was possible for me with kernel 2.4 and an earlier version of Dosemu. How can I get it working? You can narrow down whether it's a kernel or dosemu issue. You say 2.4 *and* an earlier version. Which version? How about 2.4 with the current dosemu? I don't have SCSI hardware so it's difficult to test or say much about it. Bart - To unsubscribe from this list: send the line unsubscribe linux-msdos in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Disable stretching of mode 13h while fullscreened?
On Tue, 14 Sep 2004, Dave Ahlswede wrote:
This is most peculiar. It's apparently requesting 320,200, and getting a
320x232 window. (I happen to have a number of other exotic modelines,
primarily for XMame, and 320x232 is among them).
quoth the logfile:
X: vidmode asking for (320,200); setting (320,232)
ok. I can see where it goes wrong now. Can you try the patch below?
Bart
--- src/env/video/X.c.~1.43.~ 2004-08-15 00:41:39.0 +1200
+++ src/env/video/X.c 2004-09-15 20:00:23.0 +1200
@@ -2534,8 +2534,8 @@
for (i=0; imodecount; i++) {
if ((vidmode_modes[i]-hdisplay = w)
(vidmode_modes[i]-vdisplay = h)
- (vidmode_modes[i]-hdisplay nw)
- (vidmode_modes[i]-vdisplay nh)) {
+ (vidmode_modes[i]-hdisplay = nw)
+ (vidmode_modes[i]-vdisplay = nh)) {
nw = vidmode_modes[i]-hdisplay;
nh = vidmode_modes[i]-vdisplay;
j = i;
-
To unsubscribe from this list: send the line unsubscribe linux-msdos in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Dos App hangs with DPMI / PIC problem
On Wed, 15 Sep 2004, anon permutation wrote: The other thing is that you can try patching the conditional jump immediately after that comparison that never succeeds: c316:9036 F64408FF test[si+0x8],0xff c316:903a 7408 je 9044 how do i patch this jump? in dosdebug type: e c316:903a 75 that will change the je to jne. I had to do something similar for command keen 4, it was hanging in a very similar way. Bart - To unsubscribe from this list: send the line unsubscribe linux-msdos in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Dos App hangs with DPMI / PIC problem
On Wed, 15 Sep 2004, Ryan Underwood wrote: On Wed, Sep 15, 2004 at 08:54:17PM +1200, Bart Oldeman wrote: On Wed, 15 Sep 2004, anon permutation wrote: The other thing is that you can try patching the conditional jump immediately after that comparison that never succeeds: c316:9036 F64408FF test[si+0x8],0xff c316:903a 7408 je 9044 how do i patch this jump? in dosdebug type: e c316:903a 75 that will change the je to jne. I had to do something similar for command keen 4, it was hanging in a very similar way. Are you speaking about during the system features detection (the first screen)? Yes. I have a hang there too, and in fact any similar ID/Apogee game which has a screen like that. I haven't any idea what it's sitting there waiting on The timer interrupt generator is reprogrammed, and the loop is waiting until the timer interrupt has a counter set to a specific value. dosemu can't keep up (100 Hz), and has to catch up. So the program sees the value increasing by amounts 1. This means that the counter never reaches *exactly* the value the program wants to see, it steps over it. Your /dev/rtc patch may help, but I haven't checked that. Bart - To unsubscribe from this list: send the line unsubscribe linux-msdos in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Disable stretching of mode 13h while fullscreened?
On Mon, 13 Sep 2004, Dave Ahlswede wrote: Is there a way to prevent dosemu from vertically stretching the video when it's put into fullscreen mode? It seems not to respect the _X_aspect_43 option. no, wouldn't be a bad idea though, to have a way to force vertical stretching to be equal to or an integer multiple of horizontal stretching. That's not the same as 4:3 however. Right now, X_aspect_43 transforms a 320x200 mode into 640x480 in a *window*. Probably not what you want for fullscreen 320x200. I do have a 320x200 modeline for Xfree86 setup specifically for DOS games (dosbox seems to respect it), and a lot of games look terrible when stretched in fullscreen. if you have a 320x200 modeline then dosemu should respect it as well (it does for me -- even without a modeline; adding 320x200 to the Modes line in XF86Config was enough). Please make a log xdosemu -D+X -o log and check what it does -- look for messages like this: X: vidmode asking for (%d,%d); setting (%d,%d) Bart - To unsubscribe from this list: send the line unsubscribe linux-msdos in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Virtual Console
On Thu, 26 Aug 2004, TP Reitzel wrote: Here's the latest output from boot.log after running default-configure -d and recompiling DOSEmu: Following the last legit line number (in vga.c) it crashes in vga_setpage() in svgalib. What's the chipset you configured svgalib to use? nv3? IMHO being able to use svgalib+dosemu is sheer luck, and highly hardware dependent, that's why it's not compiled in by default. You mentioned though that the only thing you changed was the kernel version right (it worked on 2.4.x but not 2.6.x?) In any case you could try $_chipset = plainvga. No guarantees though, but if the console runs in text mode (no fbdev) that normally works, at least for basic VGA graphics mode, and ctrl-alt-fn flipping with other text consoles. Personally I use fbdev on the console with an ATI card. lspci -vv mentions under :01:00.0 VGA compatible controller: ATI Technologies Inc Radeon Mobility M6 LY (prog-if 00 [VGA]) ... Region 1: I/O ports at c000 [size=256] Respecting this, using plainvga and $_console_pci = (on) $_console_ports = fast range 0xc000,0xc0ff DOSEMU works for me even with fbdev (radeonfb) but vc switching is completely broken (ie. entering dosemu that way temporarily causes Linux to be single-tasking ignoring remote connections), so this still not very nice (I rarely use it, except for comparing bugs in VGAEMU with the real thing, thus avoiding a reboot). Anyway, maybe this gives you some ideas about alternatives. Bart - To unsubscribe from this list: send the line unsubscribe linux-msdos in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: help with A and S
On Tue, 1 Jan 2002, efm wrote: hello, i try dosemu but the A and S button are not functioning, i've searched the forum, but i don't understand what they are saying. pls help me, thank you We don't know what causes it, just that it only happens for certain keyboard definitions with dead keys, perhaps only if you use unicode on the console. The workaround is to edit ~/.dosemurc or /etc/dosemu/dosemu.conf and change the line that says # $_layout = auto to $_layout = us or the country code that is appropriate for your keyboard. Bart - To unsubscribe from this list: send the line unsubscribe linux-msdos in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: another small question: ram size in dosemu
On Sun, 22 Aug 2004, Oliver Sorge wrote: i want to have 128MB of ram available for my DOS aplications. but when i try to set -M 131072 at the command line, my application says it has got just 19MB of memory. when i set $_xms or $_ems to 131072 in the configuration file, my application says it has got just 19MB too. i can't find any other thing to increase the amount of ram available to DOS :( -M is just for base memory (under 1 MB). When your application detects 19M of memory it may be DPMI (the default is 20M). Perhaps $_dpmi = (131072) helps. Bart - To unsubscribe from this list: send the line unsubscribe linux-msdos in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Dosemu Php problem
On Sat, 14 Aug 2004, Eric Day wrote: I have a Linux Mandrake 10 with DosEmu 1.2.2.0 installed. It works perfectly. I have a batch file that is executed like this: ENVVAR=e:baker1.bat /usr/local/dosemu/dosemu dumb quiet input \r When I execute from a terminal screen as user nobody, it works perfectly. But when I execute it from PHP, it doesnt (I get the You are starting this script from the wrong directory... message). My PHP setup is using the nobody/nogroup user. What am I doing wrong or missing? You probably need to set $HOME to an existing home directory that nobody/nogroup can read. Bart - To unsubscribe from this list: send the line unsubscribe linux-msdos in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Keyboard weirdness
On Sat, 24 Jul 2004, Jan Willem Stumpel wrote: On my new computer (on which I compiled dosemu again) the keyboard behaves strangely in xdosemu: lots of keys do not work. E.g. qwertyuiop becomes qwt. Is there any relation with $_layout? i.e. do the problems with s, q and e occur for in the same way for both $_layout = auto and $_layout = us ? Bart - To unsubscribe from this list: send the line unsubscribe linux-msdos in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Keyboard weirdness
On Sat, 24 Jul 2004, Jan Willem Stumpel wrote: Yes! $_layout = us solves it. But I never needed this before. The conf file says that auto tries to generate the table from the current Linux console settings. Where exactly does it look? Apparently there is something wrong with my present console settings. Maybe, but there were two others with keyboard problems as well. Maybe it depends on unicode_stop or unicode_start on the console, but that doesn't appear to be the case for me (I can't reproduce it). Please try the following with $_layout=auto: Change the two #if 0's before pretty_keysym and printf in src/plugin/kbd_unicode/keymaps.c to #if 1 and recompile. Then please report what's printed to stdout. Bart - To unsubscribe from this list: send the line unsubscribe linux-msdos in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [announce] dosemu-1.2.2
On Tue, 20 Jul 2004, Ralph Alvy wrote: [EMAIL PROTECTED]:~/dosemu-1.3.1/bin$ ./xdosemu ERROR: cpu exception in dosemu code outside of VM86()! trapno: 0x0e errorcode: 0x0006 cr2: 0x053f3805 eip: 0x40165512 esp: 0xb79c eflags: 0x00210207 cs: 0x0023 ds: 0x002b es: 0x002b ss: 0x002b Page fault: write instruction to linear address: 0x053f3805 CPU was in user mode Exception was caused by non-available page Attached is my boot.log. We'd like to see boot.log when DOSEMU has crashed, not when it has terminated normally. Alternatively try xdosemu -o logfile.txt make it crash and send the contents of logfile.txt. Please make sure you have gdb installed. Bart - To unsubscribe from this list: send the line unsubscribe linux-msdos in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [announce] dosemu-1.2.2
On Tue, 20 Jul 2004, Ralph Alvy wrote: patch lpt2.diff and try again. Bart I mean, should that have been patch -p0 lpt2.diff instead? yes, sorry for forgetting that -p0. Bart - To unsubscribe from this list: send the line unsubscribe linux-msdos in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [announce] dosemu-1.2.2
On Mon, 19 Jul 2004, Ralph Alvy wrote: I downloaded and successfully compiled and installed dosemu 1.3.1. I find the same problems with printing that I outlined before. I assume that 1.3.1 has the patch you talked about earlier. No, 1.3.1 was released on the same day as 1.2.2, it doesn't contain Stas' fix. Since you have successfully compiled and installed 1.3.1, you've done most of the hard work already. What you'd need to do is: save Stas' patch as lpt.diff in the dosemu source directory, and cd to it. Then type patch -p0 lpt.diff make su make install Bart - To unsubscribe from this list: send the line unsubscribe linux-msdos in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Compilation problems with dosemu 1.2.2
On Tue, 13 Jul 2004, Bernhard Bialas wrote: Hello, when I try to compile the dosemu 1.2.2 I get the following error message: * [EMAIL PROTECTED]:/usr/local/dosemu-1.2.2 make autoreconf Can't exec aclocal: Datei oder Verzeichnis nicht gefunden at /usr/bin/autoreconf line 174. Use of uninitialized value in pattern match (m//) at /usr/bin/autoreconf line 174. Can't exec aclocal: Datei oder Verzeichnis nicht gefunden at /usr/share/autoco nf/Autom4te/FileUtils.pm line 288, GEN0 line 832. autoreconf: failed to run aclocal: Datei oder Verzeichnis nicht gefunden make: *** [configure] Fehler 1 [EMAIL PROTECTED]:/usr/local/dosemu-1.2.2 The translation for Datei oder Verzeichnis nicht gefunden in the a.m. message is: File or directory not found My system is: - distribution: SuSE Linux 9.1 - Kernel 2.6.4 (patched by SuSE) - gcc 3.3.3 The strange thing is, that I can compile the Dosemu 1.3.1. there's a timestamp problem. Please do touch configure and run make again. I'll fix it in dosemu-1.2.2.tgz Bart - To unsubscribe from this list: send the line unsubscribe linux-msdos in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[announce] dosemu-1.2.2
A new stable version is out, 1.2.2, and you can obtain it from http://www.dosemu.org/stable Version 1.2.2 (2004-07-11) = * Backported bitmap font support for xdosemu from the development code. These are used by default! If you want to use the X fonts you must explicitly set $_X_font=vga or use xmode -font vga at the DOS prompt. $_X_bilin_filt=(on) may help for prettier fonts in full-screen mode and scaled windows. * Backported via-Unicode translations for filenames on lredir'ed drives (from iso-8859x to cpxxx and so on). * The hogtheshold code was reorganized to be able to pass through certain events quicker (such as loading a file in FreeDOS EDIT) even when you have it set to 1. * Fixed all new warnings with GCC 3.4. * Fixed compilation problem with Fedora Core 2 headers. * Added cp895 and bg-mik character set support. * Many VGAEMU bugs were fixed, and bitmap fonts are much quicker. * Allow fast i/o ports above 0x400 for kernels that support it (2.6.7-mm kernels only for now) * Implemented VxD hooks for WinOS2: seems to solve all remaining problems with Win3.1(WinOS2): allows Alt-Tab and the timer. * Some non-intrusive DPMI and DOS extender fixes. * An automatic backtrace using GDB (output in ~/.dosemu/boot.log) is attempted when DOSEMU crashes. * Serial code fixes. * Corrected int15/ax=e801 for so $_xms 64M is reported correctly by MEM. * Fix NPTL issues when switching VC's on the console. * Check /proc/net/ipx/route etc for kernel 2.6.x. * Fixed read/write problem for files with negative file offsets on lredir'ed drives. List of SourceForge tracker numbers with bugs that were closed: #885692 (Support) Serial port problem #909015 bugs/suggestions concerning DOSEMU's DPMI implementation (partly) #909588 keystroke command kills dosemu #911174 Problem with graphics under X #929123 Microsoft LINK.EXE 5.31.009 causes segmentation fault #930572 Only the half of the screen is displayed in xdosemu #934921 pmode/w extended 32bit dos app causes DOSEMU to terminate #944346 Serial port trouble #951087 IPX and kernel 2.6.5 #958717 Only small part of the screen visible under X #959015 dosemu xterm mouse network traffic #962683 graphical problems with win98/DOS #982872 Regression with VGA emu #984975 (Patches) Console S3 graphic: No portserver - To unsubscribe from this list: send the line unsubscribe linux-msdos in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[announce] dosemu-1.3.1
A new bleeding edge developer's release was uploaded. As with 1.3.0 this is a reflection of CVS HEAD, and only source code (no binaries) is available, at http://www.dosemu.org/bleeding Version 1.3.1 (2004-07-11) = * Support for 32rtm extender was added. It is now possible to use the 32bit Borland tools under dosemu. * Support for the HX DOS Extender was added. It is now possible to run some win32 console apps under dosemu, using that extender. * The Blinker extender is now fully supported (all known versions). But some older versions of that extender may require the 2.4.x linux kernel (linux-2.6.8 will include the necessary fix). * Improved DPMI uncommitted memory support (started in 1.3.0). * The hogtheshold code was reorganized to be able to pass through certain events quicker (such as loading a file in FreeDOS EDIT) even when you have it set to 1. * Fixed all new warnings with GCC 3.4. * Fixed compilation problem with Fedora Core 2 headers. * Added cp895 and bg-mik character set support. * Many VGAEMU bugs were fixed, and bitmap fonts are much quicker. * Allow fast i/o ports above 0x400 for kernels that support it (2.6.7-mm kernels only for now) * Implemented VxD hooks for WinOS2: seems to solve all remaining problems with Win3.1(WinOS2): allows Alt-Tab and the timer. * Many DPMI and DOS extender fixes. * An automatic backtrace using GDB (output in ~/.dosemu/boot.log) is attempted when DOSEMU crashes. * Serial code fixes. * Corrected int15/ax=e801 for so $_xms 64M is reported correctly by MEM. * Fix NPTL issues when switching VC's on the console. * Check /proc/net/ipx/route etc for kernel 2.6.x. * LFN (long file name) fixes. Still needs more testing * Fixed read/write problem for files with negative file offsets on lredir'ed drives. List of SourceForge tracker numbers with bugs that were closed: #885692 (Support) Serial port problem #902742 bug in DOSEMU's DOS API translation #909015 bugs/suggestions concerning DOSEMU's DPMI implementation #909588 keystroke command kills dosemu #911174 Problem with graphics under X #929123 Microsoft LINK.EXE 5.31.009 causes segmentation fault #930572 Only the half of the screen is displayed in xdosemu #934921 pmode/w extended 32bit dos app causes DOSEMU to terminate #944346 Serial port trouble #951087 IPX and kernel 2.6.5 #958717 Only small part of the screen visible under X #959015 dosemu xterm mouse network traffic #962683 graphical problems with win98/DOS #982872 Regression with VGA emu #984975 (Patches) Console S3 graphic: No portserver - To unsubscribe from this list: send the line unsubscribe linux-msdos in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
DOSEMU-1.2.1.2 prerelease for testing.
Hi, http://dosemu.sourceforge.net/prereleases/patchset-1.2.1.2.tgz is (hopefully) the last prerelease patchset before 1.2.2. Important changes: Fixed compilation problem with Fedora Core 2 Backported and fixed remaining issues with the xdosemu bitmap font support from the development version. Many VGAEMU related fixes. Some serial and console fixes. Backported via-Unicode translations for filenames on lredir'ed drives (from iso8859x to cpxxx and so on). I left the LFN code and VFAT read short file names from the disk instead of mangling from the long names code out of the stable version for now as that still needs more testing. One of these days I'm going to put up a 1.3.1 development tarball as well (basically current CVS with updated changelog). Bart - To unsubscribe from this list: send the line unsubscribe linux-msdos in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Compiling on OpenBSD
On Sun, 20 Jun 2004, Simon Wunderlin wrote: i try to compile 1.2.1 on openBSD, however, i haven't gotten over the ./configure script yet. first of all, are there any chances that dosemu will compile on a bsd derived system (or is it written for linux only)? There was a netbsd port up to version 0.99.13 or so, that was removed because it had been unmaintained for a couple of years (but of course you are free to look it up if you're willing to spend some effort on it). So if you want to get dosemu running on OpenBSD you'll have to go through quite a bit of effort, getting it to compile is just the first step. Probably the configure script relies on a few GNUisms that aren't in *BSD and that's what you ran into. Bart - To unsubscribe from this list: send the line unsubscribe linux-msdos in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Crashes if running WordPerfect 5.1
On Sun, 30 May 2004, Stas Sergeev wrote: What I mean is: You have a 4K-region aliased like this: 0x4002 - 0xe Then you resize it to 8K. With mremap() the above alias should still be valid (I think), and with memcpy() you'll have to update the mapping explicitly. Yes that's right. The first 4K still map to the same virtual file with mremap. emm.c I think expects it only to behave as a plain realloc, historical reasons probably and that's why it works. a real file you'd have to ftruncate it to the new size first. But here we don't have a fd to call ftruncate. But I wonder if SIGBUS is a correct behaviour. I would expect mremap() (nopage handler actually) to do everything that necessary, including ftruncate(). Otherwise it looks broken to me. Maybe, but that's more of a kernel issue. mmap certainly isn't guaranteed to extend a file (it works to create a new file though), so in that way mremap is behaving consistently (i.e. if you mmap bytes 4096-8191 of a file with size 4000 you can't expect that file to be extended to 8192 bytes, the same is true for shm virtual files. Look at the ftruncate example in info libc to see how they really need the ftruncate. So should we get back to pagemalloc for mapshm then? After all we still don't need IPC SHM, and pagemalloc perhaps doesn't really hurt? I think I would personnally like it best if there wasn't a pagealloc either, but just multiple fd's. That way you can have only one mapping backend, it just differs in what the fd opens (i.e. /dev/zero or a temporary file, or perhaps shm_open), and we don't need the mremap trick. That would mean that open_mapping doesn't have to do anything at all. alloc_mapping opens a /dev/zero or tmpfile -- the fd will be remembered (linked list connecting it to the memory address) or it can be returned to the caller. realloc_mapping would have to do ftruncate and then mremap alias_map can mmap from the memory region to the fd. of course the drawback of this is some overhead taking care of the fd's. But that gets rid of the overhead in pagemalloc.c and only allocates on demand (instead of one big chunk in the beginning). Bart - To unsubscribe from this list: send the line unsubscribe linux-msdos in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Crashes if running WordPerfect 5.1
It smells a bit like a kernel bug: the program below gives a bus
error...
#define _GNU_SOURCE 1
#include unistd.h
#include sys/mman.h
#include stdio.h
int main(void)
{
char *p = mmap(0, 4096, PROT_READ|PROT_WRITE, MAP_SHARED|MAP_ANONYMOUS, -1, 0);
p[0] = '1';
printf(p = %p, p[0] = %c\n, p, p[0]);
p = mremap(p, 4096, 8192, MREMAP_MAYMOVE);
printf(after mremap p = %p, p[0] = %c\n, p, p[0]);
p[4096] = '2';
return 0;
}
to followup, no it's not a bug.
replacing with
int fd = open(/tmp/foo, O_RDWR);
char *p = mmap(0, 4096, PROT_READ|PROT_WRITE, MAP_SHARED|MAP_ANONYMOUS, fd, 0);
also crashes.
For shared anon mappings mmap creates a 4096 bytes sized virtual file. For
a real file you'd have to ftruncate it to the new size first. But here we
don't have a fd to call ftruncate. We would only be able to use
ftruncate+mremap with explicit /dev/zero mappings or shm_open (best
would be to use a different fd for each memory type), but of course that
would be more involving.
Bart
-
To unsubscribe from this list: send the line unsubscribe linux-msdos in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: f11 and f12
On Sun, 30 May 2004, Cheryl Homiak wrote: I find that since upgrading to dosemu-1.2.1 I can not access F11 and F12 in MegaDots, a program for braille translation and formatting. When I try F11 or F12 in this program, it complains about that macro not existing. Is this a known program and is there something I can do about it? depends where you use it. Terminal? Console? X? On the console $_rawkeyboard may help (dosemu -k). Otherwise try shift-f1, many terminals don't distinguish between shift-f1 and f11. If all else fails ctrl-6 - (that is ctrl+six then minus) and ctrl-6 = should work. Bart - To unsubscribe from this list: send the line unsubscribe linux-msdos in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Crashes if running WordPerfect 5.1
On Sat, 29 May 2004, Lars Bjørndal wrote: I've upgraded my Red Hat Fedora to Core 2. Then, I also had to upgrade Dosemu, and I picked the latest CVS (yesterday evening). Now, I can not run WordPerfect 5.1 any more, Dosemu crashes. It's very important for me to be able to run wp. What can I do to this? Now that you mention it I can only confirm that WP crashes on the current CVS, it's not Fedora specific. It doesn't crash on the stable branch or plain 1.2.1 though. Bart - To unsubscribe from this list: send the line unsubscribe linux-msdos in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Crashes if running WordPerfect 5.1
Hi,
Lars_BjÛrndal wrote:
Dosemu, and I picked the latest CVS (yesterday evening). Now, I can
not run WordPerfect 5.1 any more, Dosemu crashes. It's very important
for me to be able to run wp. What can I do to this?
You can set
$_mapping = mapfile
in your dosemu.conf.
The patch below also does the job. As far as I could see DPMI no longer
calls this function so I guess I could remove the comment whilst I was at
it.
Bart
--- src/arch/linux/mapping/mapshm.c.~1.11.~ Sun May 9 11:39:26 2004
+++ src/arch/linux/mapping/mapshm.c Sat May 29 21:40:08 2004
@@ -147,15 +147,23 @@
munmap(addr, mapsize);
}
-/*
- * NOTE: DPMI relies on realloc_mapping() _not_ changing the address ('addr'),
- * when shrinking the memory region.
- */
static void *realloc_mapping_shm(int cap, void *addr, int oldsize, int newsize)
{
+ void *ret;
Q__printf(MAPPING: realloc, cap=%s, addr=%p, oldsize=%x, newsize=%x\n,
cap, addr, oldsize, newsize);
- return mremap(addr, oldsize, newsize, MREMAP_MAYMOVE);
+
+ if (newsize = oldsize)
+return mremap(addr, oldsize, newsize, MREMAP_MAYMOVE);
+
+ /* expanded new memory is apparently not shared so can't be aliased.
+ so we must allocate a new region and memcpy to it */
+ ret = alloc_mapping_shm(cap, newsize);
+ if (ret != MAP_FAILED) {
+memcpy(ret, addr, oldsize);
+free_mapping_shm(cap, addr, oldsize);
+ }
+ return ret;
}
static void *mmap_mapping_shm(int cap, void *target, int mapsize, int protect, void
*source)
-
To unsubscribe from this list: send the line unsubscribe linux-msdos in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: midid?
On Sat, 15 May 2004, Cheryl Homiak wrote: I'm wanting to set up sound in dosemu. I read the sound-usage.txt and wanted to use midid; I do have a ~/.dosemu.run/dosemu-midi. However, I have no midid. I didn't see anything in the debian changelog or readme to indicate it had been omitted. sorry if i've missed this and it's obvious, but can somebody please explain this? There is not much we can do about this. You should file a bug report with Debian then. Try reportbug at the Linux shell prompt. Bart - To unsubscribe from this list: send the line unsubscribe linux-msdos in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: autoexec file
On Sat, 15 May 2004, Cheryl Homiak wrote: I did RTM, but I didn't understand it and your explanation didn't shed any light on the matter. I do realize this is a different version of dosemu; however, I have been using dosemu for two years with an autoexec.bat for native dos, an autoexec.emb for most of my dosemu work, and an autoexec.brb for use with a special program for which I needed different settings and had another conf file for it. all of this worked fine. So i'm still not understanding what is changed that i now have to type a shell command to do this; obviously there has been a change and I would like to understand it. There was no need to assume I didn't RTM!!! Support for $_emubat was removed because it was broken and confusing. So you now have to type that SHELL command in config.sys instead. The problem was, if you booted with $_emubat = xxx, and you edited autoexec.bat you'd really edit autoexec.xxx. The real autoexec.bat would be inaccessible. But this faking only worked at a high level for some DOS commands, not with disk editors on hard disk images for instance. For config.xxx the heuristics are reliable enough to ensure that the DOS really only reads from config.xxx when it boots: once you edit config.sys you edit the real config.sys. Those heuristics did not apply very well to autoexec.bat. In short emubat opened a can of worms -- SHELL is much more reliable because nothing is faked, DOS knows what it does. Bart - To unsubscribe from this list: send the line unsubscribe linux-msdos in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: dosemu crashing with meminfo error
On Thu, 13 May 2004, Cheryl Homiak wrote: Is there anything I can do in my current dosemu.conf to solve the problem or do I need to bite the bullet and upgrade? yes. There are many problems otherwise, you only saw one of these. Kernel 2.6.5 can also be problematic for dosemu by the way, 2.6.6 is better. Bart - To unsubscribe from this list: send the line unsubscribe linux-msdos in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Print command
On Tue, 11 May 2004, Kovacs Alpar wrote: I can't find the dos's 'print' command . (bad command or file name) What's wrong? I don't know what's wrong but you can print a file using copy filename prn 'print's background printing doesn't make much sense in DOSEMU since Linux handles that via lpr etc anyway. Bart - To unsubscribe from this list: send the line unsubscribe linux-msdos in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: KDE Screensaver and Enter key
On Thu, 13 May 2004, Ralph Alvy wrote: Ralph Alvy wrote: I notice that under dosemu 1.2.1, when the KDE 3.2.2 Screensaver is active, after I type my password and hit Enter, the Enter key is picked up by dosemu. Is there a way around this? And this happens also when running dosemu 1.2.1 under Xfce4 with xscreensaver as my screensaver manager. I've seen it myself while flipping windows with alt-tab, sometimes the FreeDOS command.com would pick up the tab and try to do filename completion at the prompt [beep!] What actually happens is that as soon as the xdosemu window becomes active it reads the current X keymap, which of the keys are pressed and so on. So it finds out that (say) the Enter key is still pressed. It then simulates a press Enter to DOS so that the release will be processed correctly. This problem is really quite difficult to solve, I don't know how. A timeout would be something but then some keys may be missed... I tried a couple things around it but it always brought up a new (and worse) problem. An example is having the shift key pressed while your mouse moves to the window, then you expect capitals, so a press shift key must be simulated. Now do the same with ctrl while getting into DOOM... and it is used a shooting key. So in general it is difficult to distinguish special keys from non-special keys because we don't know what the program wants. Anyway I hope you get the idea. Bart - To unsubscribe from this list: send the line unsubscribe linux-msdos in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: dosemu, ipx and kernel 2.6
On Wed, 5 May 2004, Marek Korbus wrote: ...with kernel 2.4 everything is ok. Dosemu is looking for /proc/net/ipx_route and ipx is working well. But kernel 2.6 have this in different places /proc/net/ipx/route and dosemu is not able to find this and I can't run dosemu with ipx. Please help me to resolve this problem. How to tell to dosemu to look this file in different places or how to tel to kernel to put this to different places. please check the archives, they are searchable. http://marc.theaimsgroup.com/?l=linux-msdosm=108296857401869w=2 Bart - To unsubscribe from this list: send the line unsubscribe linux-msdos in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Clipper in protected mode
On Thu, 6 May 2004, Miroslav [utf-8] Lazarević wrote: Can somebody help me about starting Clipper program linked so it running in protected mode? I linked Clipper application with blinker using BLINKER EXECUTABLE EXTENDED directive but I can't start it within DOSEMU 1.2.0 with Freedos. Program reports that it can't find memory manager for DPMI, VCPI or XMS. DOSEMU after start reports it using DPMI 0.9, in dosemu.conf I found that DPMI,XMS and EMS is allocated but program wasn't start. Under Win98 dos window the same Clipper application works. Support for this was only recently implemented and required some nontrivial changes. For now it's only available in the development CVS (HEAD). Bart - To unsubscribe from this list: send the line unsubscribe linux-msdos in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: program crash xdosemu
On Thu, 6 May 2004 [EMAIL PROTECTED] wrote: I'm trying to run a program under dosemu 1.2.0 with freedos The program uses a TSR program (HSGR from PC Soft) for graphic visuals. Except for graphics, the program runs fine (don't crash) in xterm console (dosemu) with the standard configuration. [...] ERROR: BUG: dosemu touched the protected video memory!!! please try 1.2.1 -- a few corner cases related to this bug are fixed there. Bart - To unsubscribe from this list: send the line unsubscribe linux-msdos in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: dosemu -h
On Sun, 25 Apr 2004, Ryan Underwood wrote: In cvs dosemu, dosemu.bin -h does not longer dump the configuration: $ bin/dosemu.bin -h unrecognized option: -? strange? I only get it dumped on the screen with -h -O (also for the released 1.2.1, so it doesn't seem new to me). also getting a dosemu-1.3.0.1 USAGE: [...] bit at the end. Bart - To unsubscribe from this list: send the line unsubscribe linux-msdos in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Multi-user DOSEMU+SSH hardware requirements
On Mon, 19 Apr 2004, Michael Hipp wrote: Bart Oldeman wrote: smbfs doesn't support locks. Perhaps you have better luck with cifs (kernel 2.6.x), and samba. Samba has tons of locking options and I've used it to serve various database apps to Windows boxes. that's Samba with a Windows client. Here we're talking Samba with a Linux client which is quite different. Is there some particular way in which it doesn't have locking for DOS apps or is this a more general issue. it is a general issue. DOSEMU emulates locking via the Linux filesystem -- and some information gets lost. If you want to solve it properly you have to attach the DOS locking state to the file, record it the information to a temporary file (easy to get stale if multiple DOSEMUs are involved though...) or have DOSEMU talk directly to the Samba server to bypass the Linux file systems. This is however a non-trivial coding exercise and nobody has been bothered to implement it so far -- I certainly won't be bothered as there is not a lot to gain (except for being happy about the decrease in mailing list posts about locking problems). Maybe this post will inspire others. Or... load a DOS network client (the MS client, or mars-nwe, or) in DOSEMU and let it talk via the network instead of going via lredir. This is what several posters here mentioned and will indeed be more reliable since the Linux filesystem is bypassed, so no information is lost. ie. (here MFS is the Mach File System -- the code that DOSEMU uses to map Linux directories to DOS directories via lredir) strategy via smbfs/samba: DOS program - DOS - DOSEMU (MFS) --(info lost here)- Linux --(more info lost here)- smbfs - Samba - *nix strategy without smbfs DOS program - DOS - DOSEMU (MFS) - Samba - *nix strategy via MS SMB client/samba: DOS program - DOS - MS SMB client - DOSEMU (networking) - Samba - *nix note that I never tried this myself but it's based on my experience with the DOSEMU filesystem and what others posted. Bart - To unsubscribe from this list: send the line unsubscribe linux-msdos in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: DOS Console Graphics- not as root
On Tue, 6 Apr 2004, C Leonard wrote: How to run DOS Graphics on console, not as root user? I've seen rumors that this is supposed to work --- # addgroup dos # adduser me dos # adduser buddy dos Then, make /usr/bin/dos setuid root and executeable only by group 'dos': # chown root.dos /usr/bin/dosemu # chmod 450 /usr/bin/dosemu Now, only users in group 'dos' can run dosemu and it will run as root. --- I tried this- but no luck. The problem is that /usr/bin/dosemu is a script, and scripts can't (and should not for security reasons) be run suid-root. It runs the reduced graphics functional DOS. Am I missing a step? Is this the right approach for addressing this problem? The program you need to apply this too is /usr/bin/dosemu.bin. You might also need to edit /etc/dosemu/dosemu.users. By default it gives you console graphics only but I think the Debian setup is a little more conservative. If you use dosemu-1.2.0 or higher then it's better (a little more secure) to use sudo (see README.txt, Security), since sudo has the same effect as suid-root for DOSEMU -- will switch back to normal user -- but more fine-grained access checking, and allows you to have one single non-privileged dosemu.bin executable. dosemu -s implies sudo dosemu.bin which detects sudo, drops privileges, and switches back to joeuser. sudo dosemu (if that's allowed) runs dosemu with full root rights. Bart - To unsubscribe from this list: send the line unsubscribe linux-msdos in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: More info on lockup during startup
On Mon, 29 Mar 2004, James B. Hiller wrote: Also, it may be worth noting that I'm running XFree86 4.4.0. And I've noticed that the fc-cache command that my slackware-based init scripts run now seg faults the first time it runs, but doesn't when I then execute it manually. Don't know if this has anything to do with xdosemu and how it deals with fonts, but maybe. Thoughts? try [Options] Logo=0 BootGUI=0 in your msdos.sys file to avoid Windows showing the logo and trying to boot the GUI. Bart - To unsubscribe from this list: send the line unsubscribe linux-msdos in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: More than 3 LPTs?
On Mon, 29 Mar 2004, Michael Hipp wrote: Is there any way to use more than 3 LPTx ports? No. The BIOS (any BIOS, except the 8088 which has 4) doesn't support more than 3. I have a DOS application that needs lots of printers. This worked back when we actually run it under DOS and it works under Win98 now. (Tho I realize having that many printer ports is not really a common thing.) I'm not sure what LPTx you're talking about here. Isn't it a network printer? LPT5 does simply not exist -- and I wouldn't know which parallel port it would use from DOS' point of view... If the printer works like a file then you could just try to link to it on an lredir'ed drive in Linux (printer would be d:\printer.foo or something like that). Bart - To unsubscribe from this list: send the line unsubscribe linux-msdos in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: only lpt1: does printing
On Sun, 21 Mar 2004, Jürgen Ernst wrote: Everything is quite fine with dosemu but I'm going crazy with the printer configuration. I use dosemu on SuSE 8.2 and 9.0 and I downloaded the newest release 1.2 but printing does only on LPT1:. I've tested several possibilities. None... In the boot.log there is no change. CONF(LPT0) f: (null) c: lpr o: -Plp t: 20 port: 0 CONF(LPT1) f: (null) c: lpr o: '' t: 20 port: 0 The docu says I can list several printers separated with , in $_printer. No change. That's strange: if I put $_printer = lp1,lp2,lp3 in ~/.dosemurc I get CONF(LPT0) f: (null) c: lpr o: -Plp1 t: 20 port: 0 CONF(LPT1) f: (null) c: lpr o: -Plp2 t: 20 port: 0 CONF(LPT2) f: (null) c: lpr o: -Plp3 t: 20 port: 0 CONF(LPT3) f: (null) c: lpr o: '' t: 20 port: 0 The last entry is indeed a strange animal but should not hurt -- important difference with you is that I get the other printers listed (in dosemu 1.2.1) Bart - To unsubscribe from this list: send the line unsubscribe linux-msdos in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: How to change Dosemu files lock scheme?
On Thu, 18 Mar 2004, Flávio Eler de Melo wrote: Anyone has an idea of where in Dosemu sources I can find the section concerning files lock scheme? mfs.c, in src/dosext/mfs, lock_file_region() and share(). Problem is that DOS has 5 lock types whereas Linux only has 2 -- that's why we have to use heuristics. Samba can on the other hand adminstrate all client accesses because it's a server but a dosemu file server (serving all dosemus) does not exist simply because it's never been an itch to really scratch for the developers (I tried to improve a bit for 1.2.0 fixing things that were even problematic with just one dosemu running, but gave up after a while). You can see how files are locked using lsof. Bart - To unsubscribe from this list: send the line unsubscribe linux-msdos in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: S-Lang Error
On Thu, 12 Feb 2004, Nicolai Kuntze wrote: in my log is always this line: Slang:S-Lang Error: Inconsistency in define key. Can anyone tell me, what does it mean and if it is dangerous??? It means a certain key escape code was defined strangely by DOSEMU. Certainly not dangerous. Someday I'll have a look but it's not very important. Btw. leavedos(0|0x0) is there a meaning for the numbers in the leavedos line? Can I determine an errorcode out of it? Sometimes. If you have the source you know more quickly where DOSEMU exited from. That's all really. 0 means success. Bart - To unsubscribe from this list: send the line unsubscribe linux-msdos in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
dosemu-1.2.0.1 (1.2.1 prerelease)
I've put up a dosemu-1.2.0.1 patchset at http://www.dosemu.org/prereleases/patchset-1.2.0.1.tgz It's a patchset since it deletes a binary file which patch by itself cannot handle (as far as I know) User visible changes are (besides bug fixes; look at ChangeLog for the full list) - Add support for MIDI input. - Add support for the GPM mouse on the console - Add support for $_X_fullscreen and corresponding switch -w. - Add support for $_mouse_internal and corresponding switch -m to be able to switch off the DOSEMU internal mouse driver. Enjoy, Bart - To unsubscribe from this list: send the line unsubscribe linux-msdos in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Error starting 1.2.0
On Mon, 2 Feb 2004, Peter B. Steiger wrote:
The new release compiles without any errors, and (after carefully
backing up my previous version) I removed the 1.99.* files and installed
1.2.0 without any trouble. But when I try to run it, I get:
Error in built-in global.conf (line 263): unrecognized command
'xterm_title'
Error in built-in global.conf (line 264): parse error
it's the lexer or the parser that is problematic here. You might want to
check where xterm_title is defined in your source code: for me it's
grep -r xterm_title *
Binary file 1.2.0.0/bin/dosemu.bin matches
Binary file 1.2.0.0/bin/dos matches
ChangeLog: - Added $_xterm_title to dosemu.conf to configure or
disable
Binary file bin/dosemu.bin matches
Binary file bin/dos matches
etc/dosemu.conf:# $_xterm_title = %s - DOSEMU
etc/global.conf: $_xterm_title, $_rawkeyboard, $_video, $_console, $_graphics,
etc/global.conf: xterm_title $_xterm_title
src/base/init/config.c:(*print)(xterm_title\n, config.xterm_title);
src/base/init/lexer.l.in:xterm_titleRETURN(XTERM_TITLE);
src/base/init/parser.y.in: | XTERM_TITLE string_expr { config.xterm_title
= $2; }
src/base/init/parser.y: | XTERM_TITLE string_expr { config.xterm_title = $2; }
src/base/init/lexer.l:xterm_title RETURN(XTERM_TITLE);
src/base/init/parser.c:{ config.xterm_title = yyvsp[0].s_value; ;
Binary file src/base/init/config.o matches
src/base/init/dosemu_c.c:$_xterm_title = \%s - DOSEMU\\n\
Binary file src/base/init/dosemu_c.o matches
src/base/init/global_c.c: $_xterm_title, $_rawkeyboard, $_video, $_console,
$_graphics,\n\
src/base/init/global_c.c: xterm_title $_xterm_title\n\
Binary file src/base/init/global_c.o matches
src/include/emu.h: char*xterm_title; /* xterm/putty window title */
src/plugin/term/terminal.c: if (config.xterm_title strlen(config.xterm_title))
{
src/plugin/term/terminal.c: printf(config.xterm_title, (char *)buf);
Binary file src/lib/libbase_init.a matches
it should really be in src/base/init/parser.y{.in} and lexer.l{.in}. If
not then you should clean your source tree using make distclean and
recompile.
I copied the global.conf from 1.2.0/etc into /etc/dosemu, but from the
wording I guess it never even reaches /etc/dosemu/global.conf; it's
reading some internal list hard-coded in global_c.c
yes, that's right.
about clipper, I have 0 experience with it but if you can put a
reproduceable testcase somewhere (ie. put your program up for download) I
may have a look (as time permits).
Bart
-
To unsubscribe from this list: send the line unsubscribe linux-msdos in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: F11 key in terminal
On Fri, 30 Jan 2004, Nicolai Kuntze wrote: I need the F11 key in the terminal. Under X (dosemu.bin -X) it works perfect. What have I to do to get this key in the terminal?? the problem is that many terminals cannot distinguish F11 from shift-F1. ctrl-^ - should work though. Type Ctrl-^ h to get help about terminal keyboard workarounds. Bart - To unsubscribe from this list: send the line unsubscribe linux-msdos in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Opening a file for exclusive access in DOSEMU
On Fri, 30 Jan 2004, Vasil Daskalov wrote: I'm trying to run a Clipper database program in network mode in DOSEMU. The program opens some files for exclusive access, assuming that no other program can open them. This assumption holds true under MSDOS 6.22, Windows 2000 and other network environments. However, two instances of this program, running in two instances of DOSEMU on one Linux machine, can open these files simultaneously, ruining the program logic. The machine runs Debian Linux 3.0, kernel version 2.2.20. The fundamental problem is that DOS locking and Linux locking are inherently incompatible. The emulation attempted by DOSEMU may work or may not work. But in your case it doesn't even try since DOSEMU failed its first get lock attempt. You can try: - to run kernel 2.4.x instead of 2.2. it supports large file locking which may be more reliable. - play with $_full_file_locks in dosemu.conf or ~/.dosemurc using SHARE won't have any effect on lredir'ed drives. Bart - To unsubscribe from this list: send the line unsubscribe linux-msdos in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Control chars
On Wed, 28 Jan 2004, Jan Willem Stumpel wrote: Bart Oldeman wrote: Display of IBM control characters like ↑ (up arrow), ↓ (down arrow) [..] Or is there a trick to get these chars also while being a user? no you can't get them as a user without significant coding effort, ie. utf-8 support [..] /dev/vcsa [..] [head spins] Just to make certain: I wasn't asking about UTF-8 support in old DOS, which of course no one would expect. I´m just talking about the display of the up-arrow character, and similar IBM chars with values below 0x20, in very old DOS programs (like IBM Fixed Disk Organizer), which is OK for root but not for user. Sorry if I misunderstood you... ok. I was talking about utf-8 support in dosemu, not dos. The fundamental issue is that DOSEMU in the non-root console, just like in an xterm or via an ssh or telnet connection thinks it talks to a terminal. DOS programs or the BIOS write to video memory. DOSEMU in a terminal, if it's not in dumb mode, scans the video memory for updates and writes those updates to the terminal via a translation table character-character. If you write 0x7 to a terminal you hear a beep, so you don't get the IBM character associated with 0x7. Similar for all other values under 0x20: these are all control characters. The current DOSEMU implementation for terminals uses a 256-256 table (constructed via unicode mappings and $_internal, $_external charset). On the Linux console this is often a translation from cp437 to cp437, in an xterm commonly from cp437 to iso8859-1. Except, those characters 0x20 cannot be mapped to terminal characters 0x20, or you'd get beeps and all sorts of crazy things happening in your screen. For the same reasons, with cp437-iso8859-1, line drawing characters can't be drawn in xterms and they are approximated. Here (unlike the console in cp437 mode) the characters 0x80 to 0x9f are also forbidden. With a 256-utf8, or partially with a 256-256+acs table that problem could be avoided, even remotely via telnet and so on. This simply isn't implemented and that was what I was trying to explain. Only with root it does directly address the *real* video memory, so then DOSEMU doesn't worry about terminals at all. In xdosemu terminals aren't used either, just like writing to /dev/vcsa (see man vcsa, also not implemented in dosemu) would avoid the terminal control codes. Bart - To unsubscribe from this list: send the line unsubscribe linux-msdos in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Dosemu 1.2.0 kernel 2.6 crash
On 27 Jan 2004, Vaclav Cermak wrote: 2.6.0-1.104custom is kernel from similar rpms compiled by myself (i turned off APM support). Ok, I'll try that someday (probably next week). A couple things though: 0MB HIGHMEM available. 511MB LOWMEM available. mapped 4G/4G trampoline to 3000. you could try to turn off the 4G/4G trampoline or any other highmem options. It really isn't necessary if you only have 512MB RAM. DOSEMU may well have problems with 4G/4G today -- most likely someone will solve them in the future though. Bart - To unsubscribe from this list: send the line unsubscribe linux-msdos in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: ERROR: BUG: dosemu touched the protected video memory!!!
On Sat, 24 Jan 2004, Julius Schwartzenberg wrote:
Bart Oldeman schreef:
Were you talking about duke nukem 3d or some earlier duke?
It still doesn't work with version 1.2.0 :(
You can download the Duke Nukem I was talking about here btw:
ftp://ftp.3drealms.com/share/1duke.zip
yep, I downloaded that one. Seems to work fine for me though...
When would it happen?
I just did
xdosemu
cd duke
dn1
press s from main menu
press space twice
duke can walk left and right
which Linux kernel version are you running on? Distribution?
Can you also look up the value of eip in the dump and compare it to
bin/dosemu.map (you get this file when compiled from source code), and
give the full ~/.dosemu/boot.log contents?
Bart
(BTW Duke had a graphics glitch for me which was fixed in CVS but not in
-stable yet: but this as far as I can see should not be the cause for the
crash.
Fix:
--- src/env/video/vgaemu.c.~1.4.2.2.~ Sat Jan 17 21:59:10 2004
+++ src/env/video/vgaemu.c Sun Jan 25 13:58:51 2004
@@ -2307,7 +2307,7 @@
* Set visible text page.
*
* `vga.display_start' is set to `page' * `page_size'.
- * In graphics modes to 'page' * 'page_size' * 8 (quick workaround, FIXME!)
+ * In graphics modes the page_size is determined from memory/vga settings
*
* arguments:
* page - Number of the text page.
@@ -2320,7 +2320,13 @@
int vga_emu_set_text_page(unsigned page, unsigned page_size)
{
if(vga.mode_class != TEXT) {
-page_size *= 8;
+page_size = vga.scan_len * vga.height;
+if (page_size != 0) {
+ page_size = vga.mem.bank_pages * 4096 / page_size;
+ if (page_size != 0) {
+ page_size = vga.mem.bank_pages * 4096 / page_size;
+ }
+}
}
if((page + 1) * page_size vga.mem.size) {
-
To unsubscribe from this list: send the line unsubscribe linux-msdos in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: running masm611 inside dosemu and freedos
On Sun, 25 Jan 2004, Matthew Wilson wrote: On Sun, Jan 25, 2004 at 04:10:41PM +, Ged Haywood wrote: Of course if you have a Linux box you probably have a very much better assembler than MASM on the box already, and there are certainly free ones that you can download. I'm taking a class in assembly programming where all the assignments have to be written in MASM syntax. I couldn't find a linux assembler that couldn't work on MASM syntax, but that might be because I know so very little about the subject that I may have overlooked it. Is there a linux assembler that can handle MASM syntax? no, there isn't. There is intel_syntax in gas and NASM which can be quite close but there are important differences. Also asm code for DOS will be very different to asm code for Linux as far as interfacing with the hardware and OS (or BIOS) goes. if the book is easy to find (it was at the local Borders here) you could have a look at Jeff Duntemann's Assembly Language Step By Step which tells you a bit about the differences and what's available. http://www.duntemann.com/assembly.htm reviews are mixed though. As to masm in dosemu, this will generally work, and may be more comfortable than real DOS since it can only crash the virtual machine. However direct hardware access, IRQs and so on (one of the reasons ASM is still used is for these things, where C can be too cumbersome) DOSEMU can be quite tricky, depending on how well it emulates the hardware or how you configure it. Bart - To unsubscribe from this list: send the line unsubscribe linux-msdos in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Installing freedos
On Sun, 25 Jan 2004, Jan Willem Stumpel wrote: Wouldn't it be nice if freedos could be installed with a command like installfreedos directory Instantly transforming directory into a dosemu-bootable C: drive, with a sub-directory full of DOS utilities? Or is this already possible? yes, it's called dosemu -install. possible with the installation from source and the RPM. That might simplify a bit of the dummies page -- I'll have another look at that later; for this week I think I should take a break from DOSEMU. It eats too much time right now. Bart - To unsubscribe from this list: send the line unsubscribe linux-msdos in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
