Coding style vs legibility [was Re: [PATCH v4 01/17] x86/mpx: Do not use SIB index if index points to R/ESP]
> Certainly if you have code with an odd mix of styles it is much
> harder to read, and ultimately source code is for *humans* to
> understand. So enforcing a consistent style, even if it is not your
> own style, makes it much easier to follow!
It can. It doesn't always.
I've yet to see a coding style rule that can't profitably be broken in
at least a few cases ("profitably" here meaning, the breaking actually
improves rather than impairs readability). Truly did Emerson write
that "[a] foolish consistency is the hobgoblin of little minds".
Readability is a fundamentally subjective thing, after all, and thus
brings all of the human layer's messy inconsistency with it.
/~\ The ASCII Mouse
\ / Ribbon Campaign
X Against HTMLmo...@rodents-montreal.org
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
--
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: "EMS driver version mismatch: got 3, expected 5, disabling"
>> Teal deer: I'm getting the message in the Subject:, but can't figure >> out where to get an appropriate ems.sys. >> [...] > Remove your ~/.dosemu/* (ems.sys is there) Thank you very much! This worked (as I'm sure does not surprise anyone). However, neither the old .dosemu nor the new (I didn't actually remove ~/.dosemu, just renamed it so dosemu wouldn't find it) contains anything named EMS.SYS, nor ems.sys, nor any mix thereof. So, as happy as I am to have it fixed, I don't understand why this fixed it. /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTMLmo...@rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B -- 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
"EMS driver version mismatch: got 3, expected 5, disabling"
Okay, I was hoping to see a bit of list traffic before sending, but,
for whatever reason, I'm not seeing anything. I hope it's not some
kind of filtering spazz - though I did get the list welcome mail, so
that seems unlikely.
Teal deer: I'm getting the message in the Subject:, but can't figure
out where to get an appropriate ems.sys.
In more detail
I'm trying to use dosemu on Linux (kernel 3.13.0-48-generic, on
x86_64). The binary distribution had some X issues - but I know a bit
about X, so I cloned the git tree and started to fix them. I think I
have succeeded in fixing the immediate problem there, but now I'm
having other trouble.
The binary distribution claims to be 1.4.0.1 (in that when I run
dosemu.bin --version, the first line printed is "dosemu-1.4.0.1"); as a
disambiguator, dosemu.bin's MD5 hash is
60bf29180c9270018f6ba8f246e57a41. But when I base my stuff on commit
77c5e739bf5f128802ef55763909568008eac6f0 ("Tagging 1.4.0.1", the only
child of commit 74b00d8d5b46d20ce384ab64544ea41a389afe70, "DOSEMU
1.4.0.1"), all I ever get is segfaults on startup after a complaint
about how LOWMEM mmap is failing. The binary distribution's dosemu.bin
does print
EXPERIMENTAL: using non-zero memory base address 0x11.
and strace leads me to think this is relevant (in that it's printed
immediately after the same mmaps fail, but then two more mmaps are done
with addr=0x11). However, I can't find that anywhere in the
1.4.0.1 tree.
So I moved my work over to the apparent development tip, basing it at
commit 18f6f5cdf1beceae8c7532718bfaf423e4a44f6a instead. It still
crashed, but now I could find hints in the source that turning on
EXPERIMENTAL would help. It did; I then got something that would start
(and, yes, the X issue was fixed) and complain about missing DOS. So I
fetched dosemu-freedos-1.0-bin, through the chain of redirections (the
first one coming from either http://www.dosemu.org/stable/ or
http://www.dosemu.org/bleeding/):
http://prdownloads.sourceforge.net/dosemu/dosemu-freedos-1.0-bin.tgz?download
http://downloads.sourceforge.net/project/dosemu/dosemu-freedos/1.0/dosemu-freedos-1.0-bin.tgz?download=
http://superb-sea2.dl.sourceforge.net/project/dosemu/dosemu-freedos/1.0/dosemu-freedos-1.0-bin.tgz
which last finally gave me the gzipped tarball. I did a make install
with this in place as dosemu-freedos-bin.tgz and then it was willing to
start, but told me
| DOSEMU 1.4.0.8-762-g400b188 (2016-08-30), configured: 2016-08-30 12:32:33
-0400
| Please test against a recent version before reporting bugs and problems.
| Submit Bugs & Patches to linux-msdos@vger.kernel.org or via http://dosemu.org.
| FreeDOS kernel build 2036 cvs [version Aug 18 2006 compiled Aug 18 2006]
| Kernel compatibility 7.10 - WATCOMC - 80386 CPU required - FAT32 support
|
| (C) Copyright 1995-2006 Pasquale J. Villani and The FreeDOS Project.
| All Rights Reserved. This is free software and comes with ABSOLUTELY NO
| WARRANTY; you can redistribute it and/or modify it under the terms of the
| GNU General Public License as published by the Free Software Foundation;
| either version 2, or (at your option) any later version.
| C: HD1, Pri[ 1], CHS=0-1-1, start= 0 MB, size= 2000 MB
| D: HD2, Pri[ 1], CHS=0-1-1, start= 0 MB, size= 2000 MB
|
| EMS driver version mismatch, disabling.
| Please update your ems.sys from the latest dosemu package.
|
| Press any key!
and I've been unable to find an ems.sys that works any better,
including the one generated from ems.S during the build.
It's true I have local patches, but nothing I expect to be relevant. I
have made my git tree available for cloning in case anyone wants to
inspect what I have; git://git.rodents-montreal.org/Mouse/dosemu is the
thing to clone, and the local branch there is the one to look at.
(local-1.4.0.1 preserves a record of the work I did based on 1.4.0.1,
in case anyone is interested in that.) Some of the changes are pure
localisms (eg, my choice of install directory), but most aren't.
I'm not sure whether the problem here is with dosemu, with something I
did, with my expectations, or what. Any pointers would be most
appreciated.
/~\ The ASCII Mouse
\ / Ribbon Campaign
X Against HTMLmo...@rodents-montreal.org
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
--
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
Peculiar build fialure (sh "set" output appears during configuration)
Okay, my previous dosemu issues gone (thank you, list and IRC helpers!), I tried to move things to a new machine. When trying to build dosemu, I got a failure. The most obvious symptom (ie, what was visible at the end of the build) was trouble compiling int.c: gcc -c -MP -MMD -I../../../src/include -I../../../src/plugin/include -Wall -Wstrict-prototypes -Wmissing-declarations -Wnested-externs -Wno-unused-result -fno-strict-aliasing -pipe -O2 -fomit-frame-pointer -o int.o int.c int.c: In function 'dos_helper': "int.c", line 211:26: error: invalid type argument of unary '*' (have 'int') LWORD(ebx) = VERSION * 0x100 + SUBLEVEL; /* major version 0.49 -> 0049 */ ^ (plus some more cascading error messages). This made it look to me as though VERSION was defined as an empty string (I don't see how that * is unary otherwise). It also created a directory named ... whereas the working one created a similar directory named 1.4.0.8, which looks to me as though all four parts of the version number came out zero-length somehow - which matches well with VERSION being an empty string. So I did a build capturing the output and diffed it against a log of a successful build on the other machine. A few not-entirely-surprising differences, but then it went wonky. Here's the beginning of the diff: --- failing Wed Jul 24 17:24:37 2013 +++ working Wed Jul 24 17:24:38 2013 @@ -48,15 +48,16 @@ checking for connect... yes checking for remove... yes checking for shmat... yes -checking for IceConnectionNumber in -lICE... no +checking for IceConnectionNumber in -lICE... yes checking for XOpenDisplay in -lX11... yes configure: Compiling with X support... -checking for XShmPutImage in -lXext... no +checking for XShmPutImage in -lXext... yes +checking for X11/extensions/XShm.h... yes configure: Compiling without the XF86 video mode extension checking for bdftopcf... yes checking for mkfontdir... yes configure: Allowing EXPERIMENTAL stuff to be configured... -configure: Including plugins: plugin/kbd_unicode plugin/commands plugin/midimisc plugin/sdl plugin/extra_charsets plugin/translate plugin/translate/charsets plugin/X... +configure: Including plugins: plugin/sdl plugin/extra_charsets plugin/kbd_unicode plugin/translate plugin/translate/charsets plugin/X plugin/commands plugin/midimisc... configure: Compiling without debug info... configure: Compiling with ASPI support... configure: Compiling with SB Emulation... @@ -64,629 +65,35 @@ configure: Linux Specific build options... configure: Compiling with network support... configure: Compiling with default target CPU... -checking for the version of gcc.. 5004 +checking for the version of gcc.. 4006 using -fno-strict-aliasing to work around bugs -checking for glibc.. ASPI_SUPPORT=ASPI_SUPPORT=1 -AWK=gawk -BASH=/bin/bash -BASHOPTS=cmdhist:complete_fullquote:extquote:force_fignore:hostcomplete:interactive_comments:progcomp:promptvars:sourcepath -BASH_ALIASES=() -BASH_ARGC=([0]="13") ...followed by the rest of "set" output in some sh-derivative shell, presumably bash. It went downhill from there. I have the full logfiles, of course, and can make them available if that would help. This was with a fresh checkout from the same git commit that worked fine on the other machine, so I have little doubt that the starting source trees are the same. (It's commit 400b188991411f34e8df5d7eff3d184b4e358d8c in the tree I mentioned last time around. git://git.rodents-montreal.org/Mouse/dosemu/.) Both machines are running Linux - I'm told the working machine is Ubuntu 12 and the failing one is Mint 18, though I don't know either enough to be sure what that means (I'm not familiar with the differences among the various flavours of Linux). I'm wondering if this is something I've done wrong, something wrong in dosemu, something wrong in the failing system, or what. I'd welcome any thoughts anyone would care to share. /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTMLmo...@rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B -- 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: Emulated PCI devices?
>> [...] the way dosemu emulates DOS in much the same sense that wine >> emulates Windows, instead of emulating hardware proper [...] > dosemu does emulate the HW and uses freedos (or any other dos you ask > it to boot). To a point, sure. But, for example, it takes file I/O traps and provides its own implementation, backed by the host filesystem, rather than letting the FreeDOS implementation talk to (presumably emulated) disk hardware. >> [...] it involves a legacy application, running under DOS, which >> depends on a particular (relatively rare and expensive) piece of >> hardware. > If you want the DOS driver to communicate to that hardware, [...]. > If you want to emulate the "very expensive hw" without actually using > the real hw, then I wonder what's the point. The point is to get the application running without the fancy hardware (which is now EOLed) without having to rewrite the portions of the application that talk to it. The company has done an EOL buy of that hardware, but that gives them only enough to last about half the time we expect it to take to do the complete port/rewrite. /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTMLmo...@rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B -- 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: Emulated PCI devices?
> Its just that usually when you have some expensive HW, emulating it > in software is not enough because the HW is usually doing something > useful, not just makes some program to work. :) If you don't need > any functionality of that HW other than to make some DOS prog happy, Sort of. It's a (relatively-)high-speed input device, and we plan to replace it with either a pre-canned data file or a network connection as a data source. But, even once the host machine has the data, we have to get it into the program somehow. I could replace all the relevant hardware accesses with traps to the emulator, but I could also simulate the hardware it's expecting. I thought the latter was at least worth looking at; it would have the benefit that it would be running an identical software image to a real machine with real hardware, making some kinds of debugging and verification easier. > then I am afraid dosemu is not prepared for that, and you'll need to > implement the PCI emulator (in which case you can try qemu). OK, I'll talk with the other people invovled and we'll decide what tack to take: hack on the program, add PCI emulation to dosemu, switch emulators, whatever. Many thanks for all your help. Even if we end up switching away from it, dosemu has been extremely helpful in this endeavour! /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTMLmo...@rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B -- 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
Emulated PCI devices?
I'm working with dosemu and would like to add an emulated PCI device to the emulated DOS machine. Obviously, I know enough about the hardware I want to emulate to believe I can write an emulation of it. But I'm not sure where to hook it in. (I'm working based on commit 18f6f5cdf1beceae8c7532718bfaf423e4a44f6a.) I found src/base/async/pci_bios.c and src/base/dev/misc/pci.c, but they appear to be all about giving the emulated machine access to real PCI hardware on the real machine. That's not what I want; I'm trying to supply the emulated machine with hardware that is not actually present. There is src/env/video/matrox.c, which appears to be monkeying with PCI stuff, but even that checks the real machine's /proc/pci and doesn't run unless there's real hardware backing it (see matroxProbe(), which incidentally is incorrectly commented as being MGAProbe). Is this something that's already got hooks supporting it, or am I breaking new ground here? /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTMLmo...@rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B -- 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
