Re: Crashes if running WordPerfect 5.1
Hello. Lars_Bjrndal wrote: $_mapping = mapfile Yes, it worked! What happens when you spesify that? Internal thing. Temporary file is being used for the shared backing-store (for storing the DOS memory), instead of a shared mem. Since the file is being created in /dev/shm, it will not be slower than the shared mem, so you loose nothing. There is a hack now in CVS which will make WP to work again even without changing $_mapping option. That hack was posted also in that list by Bart, so you can try it, it works. But I don't think it is a good fix, to me it looks more like a temporary solution (it makes mapshm and mapfile API to behave differently, which is IMHO a potential source of troubles). I'll try to come up with something more fundamental soon, that keeps the API consistent. But you can just upgrade from CVS and forget about that problem. Or stay with $_mapping=mapfile - that also works properly. - 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
It is the console I am using, and the ctrl-6 combinations worked. Thanks. -- Cheryl Do not fear, for I am with you; do not be dismayed, for I am your God. I will strengthen you and help you; I will uphold you with my righteous right hand. - 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
adding a drive
Hi there, The concept of a built-in config file is confusing to me. Without any changes: C: points to /usr/local/share/dosemu/freedos D: points to $HOME I'm unsure about how to add a new drive that points to /usr/local/dos, where I intend to install programs. I tried: ln -s /usr/local/dos ~/.dosemu/drives/e That didn't do anything. Then in /etc/dosemu/dosemu.conf, I wrote: $_hdimage = /etc/dosemu/drives/* In /etc/dosemu/drives are the following links: c - /usr/local/share/dosemu/freedos/ e - /usr/local/dos/ But now, C: points to /usr/local/share/dosemu/freedos D: points to $HOME E: points to /usr/local/share/dosemu/freedos/ F: points to /usr/local/dos which is good, but I'd rather not have dosemu/freedos repeated. If I remove /etc/dosemu/drives/c, then dosemu won't boot at all (it can't find an operating system). So I found a way that works, but it duplicates a hard drive. So what's the proper way of adding a drive to the system? Thanks, Pete - 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
Hello. Bart Oldeman wrote: 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. I just think kernel must hide that things from userspace and resolve them internally. man mmap says: --- MAP_ANONYMOUS The mapping is not backed by any file --- So there should be no considerations about a file resizing on a userspace. For userspace it must behave as if there is no file involved, otherwise it contradicts with docs I think. What I was thinking about a cheap work around, is probably to allocate the new region the way your hack does, but then, instead of memcpy(), still use mremap() MREMAP_FIXED to remap the old region to the beginning of the new one. This will preserve the aliases, but will probably not work reliably... at least that looks extremely risky to do. - 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
Is dosemu build system not working correctly?
I think there's a problem with the dosemu build system. I'm using Debian testing. When I build with linkstatic off, everything is fine: configure: Linking for shared libraries... checking for vga_simple_init in -lvga... yes configure: Compiling with svgalib support... checking for X... libraries /usr/X11R6/lib, headers /usr/X11R6/include checking for gethostbyname... yes checking for connect... yes checking for remove... yes checking for shmat... yes checking for IceConnectionNumber in -lICE... yes checking for XOpenDisplay in -lX11... yes configure: Compiling with X support... checking for X11/extensions/XShm.h... yes checking for X11/extensions/xf86vmode.h... yes However, when building with linkstatic on, the static libraries aren't found: configure: Linking statically... checking for vga_simple_init in -lvga... no configure: Compiling without svgalib support... checking for X... libraries /usr/X11R6/lib, headers /usr/X11R6/include checking for dnet_ntoa in -ldnet... no checking for dnet_ntoa in -ldnet_stub... no checking for gethostbyname... yes checking for connect... yes checking for remove... yes checking for shmat... yes checking for IceConnectionNumber in -lICE... yes checking for XOpenDisplay in -lX11... no checking for XCloseDisplay in -lX11... no checking for main in -lXwindow... no configure: Compiling without X support... I have the following packages installed: libx11-6, libx11-dev, x-dev, xlibs-dev, libsvga1-dev The libraries really are on my system: # locate libvga.a libX11.a /usr/lib/libvga.a /usr/X11R6/lib/libX11.a But it looks like they (the static versions) aren't being found. Is this a known issue? Do I have the correct libraries installed? Thanks, Pete -- GPG Instructions: http://www.dirac.org/linux/gpg GPG Fingerprint: B9F1 6CF3 47C4 7CD8 D33E 70A9 A3B9 1945 67EA 951D Good, Fast, Cheap. Pick any two (you can't have all three) --- RFC 1925: The Twelve Networking Truths (The 7th truth) - 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
