Re: Dosemu 1.2.0 kernel 2.6 crash
On Sat, 24 Jan 2004, Disnel wrote: [EMAIL PROTECTED] disnel]$ xdosemu ERROR: unexpected CPU exception 0x0e err=0x0006 cr2=000279fe while in vm86 (DOS) means your DOS code went into zombie land. Strange. DOSEMU-1.2.0.0 is coming up on Linux version 2.6.0-1.104custom well I don't know what 2.6.0-1.104custom is. There may be all sorts of patches applied. Can you * check with the plain Linus 2.6.1 kernel -- if it works with 2.6.1 you should report a bug to the 1.104 custom patchers. * check dmesg output (kernel log messages) * if all else fails, try to link statically (linkstatic on in compiletime-settings) 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: 1.2.0 binary install
On Sat, 24 Jan 2004, Jan Willem Stumpel wrote: No, I am not worried about the bandwidth, it's probably more my feeling that the dosemu C drive should be set up in a user's home directory with its own DOS in it. that's what the dosemu script does (optionally) -- it sets up a bunch of symbolic links and a private copy of config.sys/autoexec.bat. 1.2.0 is in sid now. Thanks for the tip! This must have happened in the last few days. Pity that the Debian version does not have this handy ~/.dosemu/drives directory. In the RPM, apparently, there is a drives directory, but it is in /etc. I think it should be in the user´s home directory. the /etc/dosemu/drives/c symlink in the RPM acts as a systemwide and backup symlink. it's what is used if the user answers none to this question: Going to install your private DOSEMU-freedos files into the directory $HOME/dosemu Enter an empty string to confirm, a new path (the files will then be installed in a subdirectory named dosemu under that new path), or none (without the quotes) if you don't want a writable C-drive. Essentially DOSEMU looks for boot directories and hdimages under ~/.dosemu/, then in /etc/dosemu, and then in /var/lib/dosemu. The Debian config is just the same as it was in Debian's dosemu 1.0.2.1 -- I suppose Herbert Xu couldn't be bothered to change a lot again. It's always been a little different from what make install (or ./install_systemwide when make install didn't work) did. Whatever is better is so much a question of taste that I don't want to go into that debate now :) About the font problem. I honestly don't know what is going on. Between rc1 and rc2 I added some attempts to desperate get xset +fp ... working but apparently there's still something broken, but only for some people; for me it can find the font just fine. Seems to depend on the X server configuration. But I honestly don't know... I just can't reproduce. I also messed about a lot with xset, xfontsel, xlsfonts but nothing helped. But I could finally make it work by changing Xfonts/fonts.dir in the binary distribution (it is generated the first time that xdosemu runs). Replaced the line vga.pcf vga with vga.pcf -dosemu-vga-medium-r-normal--17-160-75-75-p-80-ibm-cp437 hmm, yes that could be it! And now I see why: the vga.pcf in the source install and in the rpm in generated dynamically (using bdftopcf from vga.bdf) but the one in the bindist is still simply copied from the old vga.pcf in etc/ in the source (which should be deleted really). -- if you copy the installed vga.pcf.gz to your Xfonts dir and then run mkfontdir it will just go fine. Time to correct this bug. Thanks for nailing it down. 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: 1.2.0 binary install
On Sat, 24 Jan 2004, Jan Willem Stumpel wrote: Bart Oldeman wrote: that's what the dosemu script does (optionally) -- it sets up a bunch of symbolic links and a private copy of config.sys/ autoexec.bat. So you set some kind of option on running the script? [at this point I thought of trying man dosemu]. I tried xdosemu -install ~/mytestdos but that does not work. Got some kind of help screen which did not mention the -install option talked about by man dosemu. What did the some kind of help screen say exactly? The -install option works differently for the dosemu script that is part of the binary tarball than for the one in the RPM or created by make install. The binary-tarball-dosemu works on the assumption that dosemu.bin lives ~/.dosemu/drives/c/../bin -- that's why its install isn't as flexible and it doesn't need to ask questions. The RPM/make install dosemu has the position of dosemu.bin hardcoded in the script (e.g. /usr/bin/dosemu.bin or /usr/local/bin/dosemu.bin). 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 :( yes, I know, noone has tried to fix it so far, and I didn't want to do it myself because that would just delay 1.2.0 even more (ie. not classified as release critical). Can you put it in the SF BTS (bugs link on www.dosemu.org) so that it won't be forgotten easily? 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: 1.2.0 binary install
On Sat, 24 Jan 2004, norseman wrote: Bart Oldeman wrote: On Fri, 23 Jan 2004, norseman wrote: MSDOS does not do network. it sure does. Think about multiple DOSEMUs running at the same time as multiple DOS clients sitting on a LAN. The lredir'ed drives look to DOS and DOS applications as network drives. Nothing more and nothing less. NO IT DON'T. IT NEVER DID. There were/are add-ons that alow network, but MSDOS as shipped by MicroSoft NEVER had network buit-in. Truth! does not do is a very broad statement. OS is very broad. What I was thinking of is you can network with DOS systems, not so much the DOS kernel supplies networking. The truth is that the DOS kernel (MSDOS, DRDOS, FreeDOS, ...) has hooks (redirector interface) that can be connected to network TSRs. These hooks are explicitly designed (better said hacked) to talk to networks. That's how I meant DOS supports (not supplies) networking. otherwise the FAT will be corrupted. multiple DOSEMUs directly accessing partitions at the same time is a sure recipe for disaster. Do it via lredir and things can go very well indeed. The method of linux# mount /dev/hda1 /dosc c:\lredir c: linux\fs/dosc is completely different. Now c: is a network drive to DOS apps. And In REAL MicroSoft_Disk_Operrating_System (MSDOS) use, having C: appear as a network drive disables a ton of software. Most Norton 4.x disk utilities (DS- directory sort, NU- direct disk util, etc) will refuse to run. sure. but I have no interest in running Norton diskedit most of the time in DOSEMU. There are Linux disk editors too. I guess it's time to ask: What are you maintaining? Is it supposed to be the ability to run actual MS-DOS as it was when it was *the* OS or something else? Running MS-DOS or FreeDOS doesn't matter. Not having to reboot to run DOS applications does. See for example if I'm hacking the FreeDOS kernel I can * have the source files (which all live on an ext3 partition) open with Emacs in Linux, can be checked in with CVS, and so on. * have one dosemu (in dumb mode) compiling the bunch with handy xterm backscrolling * one dosemu session is for testing. FreeDOS kernel compiled -- costs 2 seconds to reboot a new one. * without disturbing the session I can inspect and debug the session with dosdebug * and, as a bonus, I could do all this remotely via ssh for instance * and at the same time easily watch email, surf the net, do other stuff and fire up another xdosemu to play a nice old DOS game with full sound support. you see, dosemu enables you to do things with DOS that native DOS could never dream about... on my laptop there isn't even a FAT partition (only an image for testing) and yet I can run almost all DOS programs easily. What is FHS? www.google.com type FHS in the box, click i'm feeling lucky. 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: 1.2.0 binary install
On Fri, 23 Jan 2004, Jan Willem Stumpel wrote: Seriously: I think the binary install should do exactly the same that the (excellent) source install does; i.e. it should put exactly the same files in exactly the same locations (/usr/local) that are used by ./configure, make, [become root] make install. It should just free the dummy user from the compilation step, for which he/she most probably lacks the tools, and would be confronted with (to her/him) incomprehensible error messages because of that. In that case the RPM install is more appropriate. Seriously when I created the RPM I was wondering if I should still provide the tarball; in general users vote with feet so I put it up for rc1 and watched the statistics. For 1.1.99.1 we have from SF http://sourceforge.net/project/showfiles.php?group_id=49784 RPM: 9490 downloads Source RPM : 2906 binary tarball : 3976 source tarball : 7148 source patch : 435 So it looks like the RPM is the most popular, but there is still significant demand for the binary tarball. The point about the binary tarball (as Hans Lermen explained it, as far as I know) is that you can quickly and easily check out DOSEMU in your home directory *without needing root*. He thought building RPMs, deb's and so on was a job for distributors (many of them who get paid for just doing that after all, and we don't...) But.. DOSEMU isn't as important anymore as it used to be and some distributions no longer have it. For instance, for Red Hat versions: 6.0 (Apr 99) and all previos Red Hats had it in base (DOSEMU 0.99.10) 6.1 (Sep 99) also (ver 0.99.13) 6.2 (Feb 2000) moved it to the extras in powertools (0.99.13) 7.0 (Aug 2000) powertools (1.0.1) 7.1 (Mar 2001) powertools (1.0.1) 7.2 (Sep 2001) dropped it and Bernhard Rosenkraenzer maintained the previous RH rpm privately. DOSEMU 1.0.2 (the one where the binary tarball was introduced) was released in June 2001. It should (like the source install) also be independent of freedos, because dosemu itself is independent of it. I don't agree with that completely; that's why I included FreeDOS in the rpm. The point of the RPM is to be able to: rpm -i dosemu-1.2.0-1.i386.rpm xdosemu and it just works after answering a few questions. As part of those questions the user may point to another DOS if he wants to but he should be able to just press [Enter] a couple of times and it just works. If another DOS is used; yes it's a bit of a waste of bandwidth but that's the price you pay. And anyways many programs (think about mozilla!) are much much larger than the 2MB DOSEMU rpm. Debian users could use alien (or just get the Debian package from Debian; 1.2.0 is in sid now). So -- perhaps your DOSEMU for dummies page should point to the RPM instead? Anyway, i would welcome any documentation updates! There are even a few things on the web you could look at, e.g. http://www.wordstar2.com/dos6steps.htm http://www.linux2000.com/stsplus-linux.html http://www.rkka.org/Campaigns/dehowto.htm http://www.rkka.org/Campaigns/lindosfaq.htm http://ostrab2.potsdam.edu/CIS310/mydos/install.html http://www.linuxandmain.com/modules.php?name=Newsfile=articlesid=363 is the bee's knees as far as installation goes -- can't be _that_ difficult then ;) About the font problem. I honestly don't know what is going on. Between rc1 and rc2 I added some attempts to desperate get xset +fp ... working but apparently there's still something broken, but only for some people; for me it can find the font just fine. Seems to depend on the X server configuration. But I honestly don't know... I just can't reproduce. 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: 1.2.0 binary install
On Fri, 23 Jan 2004, norseman wrote: As long as things are getting cleaned up: I suppose it makes one think their project is bigger if they scatter it out all over the damn place. But I suggest something like: $HOME/.dosemu drives/and user's config and such /usr/local/dosemu EVERYTHING else If having a hundered directories makes one feel more important, or just not able work without them, have at it in this one spot. The FHS would actually favour /opt/dosemu instead of /usr/local/dosemu in this case. But this is problematic for several reasons: * you'd have to add something like /usr/local/dosemu/bin to your PATH (otherwise a simple dosemu wouldn't work) * you'd have to add something like /usr/local/dosemu/man to your MANPATH (otherwise man dosemu wouldn't work) so this is why make install puts most things in /usr/local/share/dosemu, and only the binaries, manpages, and documentation in other places. BIG NOTE: MSDOS itself does not support record or file locking. this is wrong: it sure does! MSDOS has had to deal with network drives for many years, since version 3.0. That's one of the reasons why the DOS SHARE command exists. Linux does and DOSEMU.bin can enforce. dosemu.bin tries to emulate file locking; if DOS tries to lock a file, then Linux tries to lock it. The main trouble is that these interfaces are horribly incompatible; it'll probably work but there are exceptions. Applies to /usr/local/dosemu/freedos and actual MSDOS partitions. exception: if a $HOME/freedos is used. Then each user would have his/her own dos world and locks would not apply. /usr/local/share/dosemu/freedos is usually readonly (except for root). Actual MSDOSpartitions or anything else that is writable are like network drives. DOS applications that must care about locking already have done so for many years. So I'm not sure what you're up to here. 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: 1.2.0 binary install
On Fri, 23 Jan 2004, norseman wrote: I suspect all the RPM people got together and padded the count. wow. Conspiracy theory. We love that right ;) The more I see and use of RPM the less I like it. It is a potential security risk. Please don't go there. RPM was selected by the people at www.linuxbase.org (LSB) as the standard binary distribution format. These are knowledgeable people. If RPM were a real security risk it wouldn't have been selected. speaking of adding things: 1) pre-compiles need to actually read a config file and accept .emu extensions instead of ignoring them. what do you mean here? $_emusys in dosemu.conf? 2) need to put himem and UMB back into operation. 1.1.99.1 reduced available memory considerably. (canceled compress.exe use) you'll have to elaborate on that. These two are active by default if you use DOS=UMB,HIGH which is in the default config.sys. MEM reports 628K (642,640 bytes) free, and 108K (110,224 bytes) free upper memory in 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: 1.2.0 binary install
On Fri, 23 Jan 2004, norseman wrote: again: /usr/local/share/dosemu is just more typing. /usr/local/dosemusee? I know, but I'm trying to follow a standard, the FHS, which may be different from the norseman standard. MSDOS does not do network. it sure does. Think about multiple DOSEMUs running at the same time as multiple DOS clients sitting on a LAN. The lredir'ed drives look to DOS and DOS applications as network drives. Nothing more and nothing less. YES - 1.0.2 and 1.1.99.1 do require a disk partition to be dismounted before they run. that's *direct* partition access you are talking about. And yes, for that ($_hdimage = /dev/hda1) you need exclusive access, otherwise the FAT will be corrupted. The method of linux# mount /dev/hda1 /dosc c:\lredir c: linux\fs/dosc is completely different. Now c: is a network drive to DOS apps. And locking may or may not be used by those applications. Just like Linux apps may or may not use locking techniques. Xtreegold, dBASE III+ WordStar 4 and a ton of other software I run on MSDOS have absolutely no concept of file locking. And never did. dBASE III+, Clipper, FoxPro, and many others have a concept of file locking and use it more or less extensively. See int21/ah=3d, modes for AL (DENYALL, DENYWRITE, DENYREAD, DENYNONE) and int21/ah=5c. Past tense used because recompiles of 1.0.2 and 1.1.99.1 fail to function on new hardware. Same OS, same install - new laptop. Fail Totally. That's the famous 2.6.1 kernel problem most likely. $_mapping=mapfile would solve it. DOSEMU 1.2 has a workaround (runtime check). Traditionally: In UNIX /bin /sbin and such are OS system files /usr/bin /usr/sbin and such are login's files /usr/local/bin /usr/local/sbin and such are files specific to local hardware and console use. like cdrecord (you know how - get the image onto a local drive, drop the net, make the burn and restart the net. Or have lots of coasters.) according to FHS: /bin : Essential user command binaries (for use by all users) /sbin : System binaries /usr/bin : Most user commands /usr/sbin : Non-essential standard system binaries (nothing to do with login --bo) The /usr/local hierarchy is for use by the system administrator when installing software locally. It needs to be safe from being overwritten when the system software is updated. It may be used for programs and data that are shareable amongst a group of hosts, but not found in /usr. Locally installed software must be placed within /usr/local rather than /usr unless it is being installed to replace or upgrade software in /usr 4.9.2 Requirements The following directories, or symbolic links to directories, must be in /usr/local /usr/local -- Local hierarchy +-bin Local binaries +-games Local game binaries +-include Local C header files +-lib Local libraries +-man Local online manuals +-sbin Local system binaries +-share Local architecture-independent hierarchy +-src Local source code No other directories, except those listed below, may be in /usr/local after first installing a FHS-compliant system. 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: 1.2.0 binary install
On Fri, 23 Jan 2004, norseman wrote: Bart Oldeman wrote: what do you mean here? $_emusys in dosemu.conf? no; .emu extensions to autoexec and config so one doesn't have to continually copy dummies to .bat .sys if booting live and another set of dummies if booting emulator. used to be autoexec.bat autoexec.emu config.sys config.emu all resided in msdos live boot partition. live boot used normal and emulator boot used .emu setups. used to be. right that's what's $_emusys does: use $_emusys=emu and dosemu will use config.emu instead of config.sys. Put SHELL=COMMAND.COM /P /K AUTOEMU.BAT in config.emu to execute something else than autoexec.bat. Then I booted Linux, started 1.0.2.? and - on same hardware, same disk, using same program and same data set ran it again. right at 20 minutes. sure, Linux is good at disk caching ... you'll have to elaborate on that. These two are active by default if you use DOS=UMB,HIGH which is in the default config.sys. nope - not in the 1.1.99.1 pre-compiled. everything loads low. not a dosemu problem I think. May have to do with config.emu stuff above; just put that DOS=HIGH,UMB in your config.sys and you'll get your UMBs and HMA. 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: no MIDI input with dosemu ?
On Tue, 20 Jan 2004, Dave Phillips wrote: The short story so far is that Stas Sergeev has posted a patch that gives MIDI input to CVS dosemu. I don't know whether Stas's patch is included with the new 1.2.0 dosemu, but I imagine it can be compiled against it anyway (Stas, any additional instructions for your patch + 1.2.0 ?). Stas' patch applies against 1.2.0; it is included in CVS HEAD now. It'll probably end up in 1.2.1 though, since it looks stable. Reason is simply that for 1.2.0 I wanted to concentrate on pure bug fixes, no new features since 1.1.99.1. Some other features that need to be stabilized a bit more but will probably end up in later 1.2s are: * GPM mouse support in the console (looks stable, but not so widely tested) * LFN support (has some problems in that it can venture outside the DOSEMU lredir sandbox if you carefully construct a pathname) * bitmap fonts. Nice new feature but it's still a little broken -- you can get black screens which can only be solved by mode co80 * internationalization of filenames and direct access to VFAT short filenames on mounted VFAT volumes * Clarence' direct dosemu /path/to/dos/command/file.exe feature. so I'm not planning to freeze 1.2.x for the time being, except for big code reorganizations, which really are reserved for 1.3. 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: Problem: DOSEMU ignores Linux user file access settings
On Mon, 19 Jan 2004, Mgr. Peter Tuharsky wrote: DOSEMU uses one strict policy when creating new file from inside emulated environment: It creates new file with 600 attrib mask and user-only gid/uid. DOSEMU fully IGNORES both bash.profile setting, and folder's SetUid/SetGid setting!! And this is the reason of my big problem. no, DOSEMU doesn't ignore them. Be careful here. What is your umask setting from bash.profile? Try a simple umask to be sure about that (in Linux) If it's 007 then new DOSEMU files (with archive bit set) are normally created as -rw-rw Also DOSEMU doesn't do chown on files so I can't see how it could ignore setgid attributes on directories -- the files will have the same owner/group as a simple file created with echo hello file would do. Try this command in Linux *and* in DOSEMU in the same directory and look at the permissions. directory dosen't help either, because DOSEMU takes .dosemurc strictly from user's home directory and this way the printing is directed to only one printer. Try -f. Also the environment variable dosemu__printer can do the trick as long as you do *not* define it in .dosemurc. 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.0
Shevchenko Antonio Larrosa Arjan FiliusArne de Bruijn Bart Oldeman Ben Davis Bernd Paysan Bernd SchuelerChristoph Niemann Clarence Dang Corey Sweeney Daniel R. Barrlow David Brauman David EthertonDavid HansenDavid Hindman David Hodges David PinsonDerek Fawcus DJ DelorieDong LiuEgbert Eich Emmanuel Jeandel Eric W. Biederman Erik Mouw Florian La Roche George K.Bronnikov Grant R. Guenther Grigory Batalov Hans Lermen Herbert Xu James Maclean Jason E Gorden Jochen Hein John DavisJohn Kohl Jon Tombs Josef Pavlik Julia A. Case Kang-Jin Lee Karl Kiniger Karl-Max Wagner Kenneth Corbin Kevin P LawtonLam Lai Yin, Savio Larry Stephan Lawrence K MaoLinus Torvalds Lutz Molgedey Manfred Scherer Marcus Better Mark Rejhon Marty Leisner Matthew Grant Maxim Ruchko Michael E. DeisherMichael Karcher Oleg V. Zhirov Pablo Saratxaga Pasi Eronen Pat Villani Rainer Zimmermann Reinhard KarcherRob Clark Robert de BathRod May Ronnie Rutger Nijlunsing Scott Buchholz Sergey Suleymanov Stas Sergeev Steffen Winterfeld Theodore T'so Tim Van der LindenUlrich Weigand Uwe Bonnes Urban Widmark Vinod G KulkarniWayne P Meissner Witold Filipczyk Wojtek Pilorz ... and others too important to mention. Of course, all those people involved in the FreeDOS development should be mentioned here too, but before I fail to mention some of them, I better point to http://www.freedos.org ;-) WHERE TO GET IT ~~~ The DOSEMU PC Emulator can be downloaded at: http://sourceforge.net/project/showfiles.php?group_id=49784 The binary package is dynamically linked against glibc-2.2 and libX* from XFree86. It should run on all recent Linux distributions. HELPING US ~~ Many thanks to all who have helped with this release, by sending bug reports, patches, comments and/or ideas for DOSEMU! Our apologies for not having answered every letter, and possibly missing some important information. If you know something you think we should know, contact us. We can be reached at: The DOSEMU Team [EMAIL PROTECTED] http://www.dosemu.org - - - - - - - - January 2004, Bart Oldeman [EMAIL PROTECTED] coordinator of The DOSEMU Team - 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.0rc2
On Sat, 17 Jan 2004, Claudia Neumann wrote: So I substituted the freedos-kernel.sys with the kernel.sys you mailed me in october and it works fine again (?). that change is just one of quite a few changes that went into the FreeDOS kernel since it's last release in September. To simplify distribution I'd like to only distribute released FreeDOS components. -- it's quite an obscure function that your program uses, feel free to use that kernel.sys I sent in October; over time dosemu-freedos will be updated again which supersedes that kernel.sys. It always takes quite a bit of time to organize a freedos kernel release, to update the dosemu-freedos tarball, make sure the sources are in sync, deal with the sourceforge file release system, ... So for now it's more efficient to keep dosemu-freedos tarball the same for a fair amount of time; it works well enough for the majority of DOS programs and for the minority it fails for people could update individual components, which is just what you did. Hope that explains the reasons behind it a bit. There is another problem: with the german keyboard layout we have a § (paragraph) at shift-3. It is ascii alt-021 and it is in the keytable de-latin1. But it doesn't work with dosemu but only gives a beep. I suspect it is missing in vga.pcf.gz, vga11x19.pcf.gz and the other fonts. I tried all the available dosemu-fonts but nothing works and since 1.1.04 we need the § (paragraph) for some medical coding. How can we get the § (paragraph) in dosemu? I'll have a look. Something trivial might be wrong in the unicode tables: if I copy and paste from man iso-8859-1 character 163 or your email to dosemu I get the British Pound sign (£). 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 on your DOSEMU request
On Thu, 15 Jan 2004, Stephen torri wrote: On Thu, 2004-01-15 at 03:38, norseman wrote: normally, in the synthetic mode, you only need the .bat/.sys files. thus the contents of the .emu files can be made the contents of the .bat/.sys files and you won't need to bother with two sets of configs. just reading the above and not having more to go on, /dev/cdrom - /dev/cdroms/cdrom0 and $HOME/.dosemu/drives/d - /dev/cdrom yes??? no! You have two alternatives to access the cdrom: a) device=cdrom.sys (in config.sys) shsucdx /d:mscd0001 (in autoexec.bat) shsucdx will tell you the drive letter. Alternatively use mscdex. b) $HOME/.dosemu/drives/d - /cdrom where /cdrom is your CD mount point. In that case you must mount your CDROM in Linux. lredir d: linux\fs/cdrom would do the same (at the DOS prompt or autoexec.bat) 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.0rc2
Hi, I put up a second 1.2.0 release candidate at www.dosemu.org. This time I hope no showstoppers are left so the only diffs will be in changing some years from 2003 to 2004. short changelog: * fixes for 2.6 kernels: DPMI was broken and mapshm doesn't work with 2.6.1 (but it will work again with kernel 2.6.2 and later) * fixes for NPTL: some signal handlers still caused crashes * try harder to find the vga font * don't use readlink in the dosemu script: it's not standard * sudo dosemu now gives full root * added $_printer_command to dosemu.conf to be able to specify lpr -l (some people reported that that is necessary for CUPS) * fix -F switch for alternative global.conf * add -n switch to be able to ignore dosemu.conf * some OSS initialization and MPU-401 sound fixes * misc other bugs fixed * async io for the serial and mouse code. 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: re. the 1.1.99.1 problem - this might help
On Tue, 13 Jan 2004 [EMAIL PROTECTED] wrote:
Steve Turner wrote:
1) get the DOSEMU precompiled tgz
2) get the freedos precompiled tgz
if either or both were {whatever}.tar.gz
then rename them to {whatever}.tgz
3) cd (or: cd $HOME )
4) mkdir dosemu
5) put BOTH downloaded tgz's in $HOME/dosemu
6) tar -xzf freedos{whatever}.tgz
do this one first or you will have problems.
even if you plan to only run real partition
you still have to do this. Yep - have to!
7) tar -xzf dosemu{whatever}.tgz
8) NOW - you must become root (su - root and give password)
mkdir /var/lib/dosemu
chmod 755 /var/lib/dosemu
[...] funny setup. This is easier done by installing the RPM or from
source. The precompiled tgz is designed to run somewhere under one's
$HOME directory without any root rights needed.
I chose to ./dos - which links to the executable dosemu/bin/dosemu.bin
which reports that my libc.so.6 lacks the needed LIBC_2.2, which is true.
As previously reported I'm using RH 6.2
With everything else being 'so alpha', I have no intention of getting
LIBC_2.2.
Apparently it is possible to drive par-port(s) from Ver 1.0.2 ?
yes and no. Not easily with the binary tarball, unless you run 1.0.2
dosemu.bin directly which requires you to put files in many different
locations.
It's easier then to run the 1.0.2.1 binary lets you run dosemu as root as
you tried with 1.0.2.
In dosemu 1.1.99.2 the readlink problem is fixed, but you'd have to
compile it from source, because of the glibc 2.2 issue; the source should
only require glibc 2.1.3.
For parallel ports this HOWTO section can help:
http://dosemu.sourceforge.net/docs/HOWTO/x249.html#AEN283
but there is still a stupid mistake in the syntax there:
the correct syntax is (if /dev/lp0 is connected with 3bc--3bf)
$_ports = device /dev/lp0 fast range 0x3bc 0x3bf
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: Problems with 2.6.X kernels and dosemu-1.0.2.1
On Sun, 11 Jan 2004, James B. Hiller wrote: Problem is that the case where new_len==0 was a security hole. Linus went one step further and also disallowed old_len==0. This is not a security hole, but deals with a somewhat tricky (and apart for source code undocumented) interface that DOSEMU happens to use. Hopefully Linus or Andrew Morton can revert it and apply this patch. Is it something you've sent in? yes. Linus applied it, see http://linux.bkbits.net:8080/linux-2.5/[EMAIL PROTECTED] and LKML As long as you don't use DPMI the workaround is enough for 1.0.2.1. Didn't have DPMI turned on in dosemu.conf (it's set to (off)), so unless it's getting set on elsewhere that I wouldn't know about, seems to be something more than this. Just curious - would you recommend going to 1.1.99? I've got the tar sitting here, just in case. In general there's no point upgrading if something works fine. 1.1.99 is much better if you want better sound, networking, DPMI (e.g. the newer games, DOOM and later), VGA emulation, fullscreen in X, ... 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 Fri, 9 Jan 2004, Julius Schwartzenberg wrote: When I run a program such as Duke Nukem, Dosemu quits with the following error: ERROR: BUG: dosemu touched the protected video memory!!! ERROR: cpu exception in dosemu code outside of VM86()! trapno: 0x0e errorcode: 0x0006 cr2: 0x000a7000 eip: 0x08092657 esp: 0xb290 eflags: 0x00200246 cs: 0x0023 ds: 0x002b es: 0x002b ss: 0x002b Page fault: write instruction to linear address: 0x000a7000 CPU was in user mode Exception was caused by non-available page ERROR: leavedos() called from within a signal context! It works fine when running with direct video access on a console. This can be tricky depending on where dosemu is. One such instance was solved fairly recently. Can you check where 0x8092657 (the value behind eip:) is in bin/dosemu.map or by using gdb? Were you talking about duke nukem 3d or some earlier duke? I tried it with Dosemu 1.2.0 RC1 and stable 2003. The DoSEMU stable 2003 you saw is a joke (witness DoS = denial of service) -- it should have been called cvs head 31 Dec 2003. Anyway I got tired of him so it no longer exists. 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 multicast w/ dosghsrv (ghost)
On Wed, 7 Jan 2004, Eric Becker wrote: (sorry for acting a bit like the Beagle 2, I'm back). I'm trying to setup dosemu so that I can run the dos multicast server from ghost. I'm actually using the supplied freedos instead of msdos. In my /etc/dosemu/dosemu.conf $_pktdriver = (on) $_netdev = tap0 $_vnet = tap If I do an lsmod I can see that tun is loaded. There's more to it: you need to set up a network interface. Read Chapter 15 of Readme.txt http://dosemu.sourceforge.net/docs/README/1.2/t1.html for details. Stas mentioned brctl -- that's advanced configuration; with the above all you have is an internal (to the machine) network with the Linux box on (say) 192.168.1.1 and the DOSEMU box on (say) 192.168.1.2. Bridging comes in handy if you're talking to the outside world http://edeca.net/articles/bridging/ says how this works in user mode linux (UML). DOSEMU works likewise. I assume I need to be loading some kind of dos network driver in freedos??? No. 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 multicast w/ dosghsrv (ghost)
On Thu, 8 Jan 2004, Eric Becker wrote: Now I'm a bit confused as to what needs to be setup by my DOS network client. Originally, I assumed that dosemu would be similar to vmware, in that I would need to load a dos network driver. But, as you stated, I won't need to load a network driver. Essentially a packet driver is built in: int 0x60. The DOS applications must then be configured individually to know what IP they have and if applicable the gateway and name server. Where to do that depends on the app. E.g. for applications that use WATTCP it's wattcp.cfg VMWARE would actually emulate an ethernet device, but DOSEMU emulates something that is higher level, the packet driver. In real mode DOS I would load a packet driver that talks to my ether net card and use that (using int60) in DOS apps likewise. However, the first set of instructions for TUN/TAP support instruct the user to Configure the DOS network clients to have another IP address within the same domain. I'm a bit confused as to what will need to be loaded on the dos client in order for it to network. Nothing loaded, just a config setting. Try NCSA telnet or SSHDOS (sshdos.sf.net) to get the idea. Bridging comes in handy if you're talking to the outside world http://edeca.net/articles/bridging/ says how this works in user mode linux (UML). DOSEMU works likewise. So then with the above setup I will only be able to communicate with the machine I'm running dosemu on? But in order to communicate with the rest of th 192.168.1.x subnet I will have to bridge tap0 with another ethernet device (i.e. eth0)? And then the dosghsrv can recieve requests from the ghost clients to broadcast the ghost images via multicast? AFAIK yes, yes, I don't know. Probably, but I never tried that myself. 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: allow access to parallel port
On Thu, 11 Dec 2003, Razvan Cosma wrote: Status update: I gave up on the direct port access, and configured CUPS. I can print just fine from Linux, and can also do a echo sdcsc LPT1: in dosemu. But the application (which does a set output to printer or however that was called in dbase) freezes when trying to print. Listing the information on the screen works though. Is there anything special about the dbase/fox stuff? you can try xdosemu -D+piT -O to figure out what is going on. Printing via lpr works using a periodic flush of a buffer that is fed by BIOS calls. Direct parallel port access will only work if the DOS application does just that. What is not (yet?) implemented in DOSEMU is DOS app (- DOS) - BIOS - emulated parallel port - whatever you like or DOS app (- DOS) - BIOS - real parallel port that is, the DOSEMU BIOS directly spools rather than via a port. 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: passthrough printing problem
On 9 Dec 2003, Guillermo Gomez wrote: I discovered the problem with my passthrough printing implementation and i don't know how to fix it. The symptom: When the passthrough printing starts the display data get mixed in the telnet fata flow. The solution would be: The app should wait for the print job to finish before taking over the display. How can this be solved? Obviously the dos application is thinking the print job is done and the display (screen) is refreshed. the only way to solve it is to think hard about a solution and implement it into dosemu (ie. non-trivial). What's the role of the timeout parameter in the printing command? printing in dosemu is pretty basic, it just collects whatever the DOS applications (or DOS itself) sends to the BIOS (int17, there is NO parallel port emulation) in a buffer and flushes the buffer using the command (lpr or vtprint in your case) every timeout time units. 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: Resources Eating?
On 8 Dec 2003, Guillermo Gomez wrote:
I compiled from source including global.conf modified as...
...
if (strlen($_printer))
foreach $xxx ($LIST_DELIM, $_printer)
## $xxx = '-P, $xxx, ';
## printer { options $$xxx command lpr timeout $_printer_timeout }
printer { options '%s' command 'vtprint -fq' }
done
endif
...
But vtprint is reporting the following message
vtprint: Couldn't open %s for reading.-
What i'm doing wrong now?
remove the %s. The command should read from a pipe now, instead of
printing a temporary file, and that's why the %s is obsolete.
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: Resources Eating?
On Mon, 8 Dec 2003, Brett I. Holcomb wrote: Just to make sure I understand this: 1. /etc/global.conf A. Don't mess with /etc/global.conf because you can break things. yes. its main job is to parse dosemu.conf. However every once in a while we encounter situations that are impossible to configure with dosemu.conf. B. I found my install left the /etc/global.conf.example and did not create a /etc/global.conf. Would that have hurt me or no is what's in the example file built into the dosemu.bin. yes 2. /etc/dosemu.conf and /etc/dosemu.users is what we work with to change global settings - correct? yes. These files can also live in /etc/dosemu. dosemu.users is optional. Only if certain users are allowed to use direct hardware i/o ($_ports and so on) through a suid-root dosemu.bin or dosemu -s with sudo, you'll need to edit it. As far as such access is concerned, only console graphics works with a privileged dosemu by default. dosemu.conf lives in the same directory as dosemu.users. 3. ~/.dosemurc is used for users who want to set up their own special settings - correct? yes. Just like /etc/profile vs. /etc/.profile. Some settings in .dosemurc are ignored for security reasons. 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 memory management
On Tue, 9 Dec 2003, Stas Sergeev wrote: Updegrove, Timothy (Tim) wrote: to the DMA hardware, map a physical address to a linear address, etc will work as is under Linux or are modifications required? This functionality is not implemented in dosemu. The relevant API is missing in a DPMI server, the $_hardware_ram option doesn't work the hardware_ram option works but is really limited, as it only works for addresses between 0xc8000 and 0xf. the example hardware_ram in dosemu.conf gives you the following mapping: 000c8000-000c9000 rw-s 000c8000 03:06 273019 /dev/mem 000c9000-000cc000 rwxp 000c9000 00:00 0 000cc000-000d rw-s 000cc000 03:06 273019 /dev/mem Where can I found documentation about the DOSEMU DPMI API for memory allocation, physical address mapping, etc? Nowhere. Nobody is working on that. So unless someone needs this badly enough to start coding it up, it will not be implemented. I don't even remember if someone ever asked about this here during the last 4 years. In general this is needed if your hardware is not supported natively under Linux, so it is not a common thing. True. And in Tim's case it would just be a layer so he can avoid porting. 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: Resources Eating?
On 8 Dec 2003, Guillermo Gomez wrote: Well i found the problem is that the global.conf is builtin is taken precdence and my modified global.conf is not doing anything. I'm trying to use the -F option with no luck..How can i dump the built-in global.conf to tweak it using option -F. Presently only by editing etc/global.conf in the source code and recompiling. dosemu.bin in the bindist can be replaced by the one you obtain that way. My installation is working ok without the -F option. it's on my list to fix for 1.2.0. -F should work. The problem is here: In file included from dosemu/dosemu-cvs/dosemu-1.1.99.1/etc/global.conf:212 Error in : (line 212) parse error Error in : (line 556) parse error Error in : (line 556) expected 'emulated' or 'native' 3 error(s) detected while parsing the configuration-file by the way, because your problem came up in different variations before the CVS version (and 1.2.0-final when released) allow you to do what you want in dosemu.conf or ~/.dosemurc: # list of (/etc/printcap) printer names to appear as LPT1, LPT2, LPT3 # (not all are needed, empty for none). Default: lp # $_printer = lp # Print command to use. Default: lpr, for lpr -P printername. # Sometimes (with CUPS) lpr -l is necessary. # $_printer_command = lpr Bart [snip] - 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: Problems running 1.1.99 + Clipper w/ Multiple users
On Wed, 12 Nov 2003, Gustavo Sverzut Barbieri wrote: 1) After running the software and accessing DBF from MS-DOS, when exiting (exitemu) I get: C:\ESMERALDexitemuERROR: lowmem_alloc failed for 10240 ERROR: Unable to allocate memory pool This used to work with 1.1.4. Running with Freedos works all right. You need to upgrade your exitemu.com too. 2) Trying to open the same DBF from withing 2 different dosemu I got this error: is it possible to download your software somewhere so it will be possible to reproduce the problem? locking is a long standing problem -- it's not possible to solve it 100% because DOS and Windows use wildly incompatible locking schemes. 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 required: DOSemu impossible to access /dev/lp0
On Sun, 9 Nov 2003, Michel van der Kleij wrote:
I'm running DOSemu 1.0.2.1 and FreeDOS 1.1.28 on Red Hat 7.3 and am unable
to access /dev/lp0 directly.
First try upgrading to 1.2.0rc1
You need root privileges since /dev/lp0 isn't accessed (just
claimed) but rather the direct I/O ports behind it.
This means that printing goes like in real DOS, no translation at all by a
Linux printer driver.
#$_printer = lexmark # list of (/etc/printcap) printer names to appear as
# LPT1, LPT2, LPT3 (not all are needed, empty for none)
#$_printer_timeout = (20)# idle time in seconds before spooling out
#$_ports =
$_ports = device /dev/lp0 fast range 0x378 0x37a
The hex values are derived from /proc/ioports, but I get no response at all
from the printer. When I uncomment the $_printer* and use just $_ports = , a
command like type autoexec.bat prn works. But the Fortran program still
does not work. Then the line below from the HOWTO:
$_ports { device /dev/lp1 fast range 0x378 0x37f }
Hmm -- the HOWTO uses old style here. You should write that as
$_ports = device /dev/lp0 fast range 0x378 0x37f
I'll update the howto to reflect 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
regarding Dosemu (fwd)
sorry, I don't have time to deal with this now (and I have zero experience with novell), forwarding to the users list. Programs that need VCPI generally don't run in DOSEMU. Turbo C++ 1.01 is a real mode program though and it runs just fine. -- Forwarded message -- Date: 28 Oct 2003 09:07:59 - From: harsha harsha vardhan [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: regarding Dosemu dear sir/madam, i already send a mail to development section i want to execute dosemu in linux server as it has been done sucessfully if i connect the linux server to the novell server i am getting the novell server in the network i couldnt able exceute Turbo C++ from the linux server it is giving the following error DPMI Server intialization errror - v86 task without vcpi so please provide solution for this i am excepting early reply thanking you harsha vardhan - 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 SPX PDETHER SOLVED!!!!
On Fri, 24 Oct 2003, Peter Eckhardt wrote: i just respond to my own mail. But as I didn't find documentation how to make the above work in current dosemus i will summarize how to get SPX working cool! I'll update the NOVELL HOWTO with your information -- that might save others some time. Just one comment, answering your question about a boot directory: 1. Create a dosemu image which uses msdos or drdos (i used drdos) Well this should not be necessary. You can just create a directory, say DOSEMU_LIBDIR/drdos, copy all your DRDOS files to it and set. $_hdimage = DOSEMU_LIBDIR/drdos. Or copy drdos' ibmbio.com/ibmdos.com/command.com to the directory that contains kernel.sys. That automatically overrides it. What is the problem with FreeDOS in this case by the 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: Latest dosemu and vga fonts
On Thu, 16 Oct 2003, Ralph Alvy wrote: Ralph Alvy wrote: Just moved from RedHat to Debian (Libranet 2.8.1), and installed the binaries with a local install. I forget how to get out of this vga error scenario (I have readlink on my system, by the way): You do not have the DOSEMU vga font installed and are running remote X. You need to install the vga font on your _local_ Xserver. Look at the readme for details. For now we start with an fixed font, which does not display all national characters correctly. ... be warned ERROR: Unable to open console to evaluate the keyboard map. Please specify your keyboard map explicitly via the $_layout option ERROR: X: Unable to open font vgaERROR: , trying vga... ERROR: X: Unable to open font vgaERROR: , trying 9x15... Just to be clear on this, the first entry for Font Path, as reported by 'xset q' is /home/ralvy/dosemu/freedos/../Xfonts try xset fp default if that doesn't help then check the contents of the above directory. 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
some comments re: dosemu 1.1.99 (fwd)
-- Forwarded message -- Date: Thu, 16 Oct 2003 10:36:22 -0400 From: Dave Phillips [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: some comments re: dosemu 1.1.99 Hi Bart: I'm currently rewriting my book (Book Of Linux Music Sound) and have just finished the Emulators chapter. I updated to the 1.2 release candidate and wanted to say a few words to you about it. First, congratulations to the entire team a job very well done. A number of minor irritations have been removed (shift-tab works in Sequencer Plus!) and overall the system is easier to use and configure (I'm using the binary distro, btw). I was especially impressed when I fired up two long-standing no joy apps under dosemu. M/pc is a Voyetra product from the late 80s/early 90s that runs under an included runtime version of Windows 2.0 (!). Back in the days of dosemu 0.66 or so I was able to run it under the emulation, but later versions didn't like it at all. 1.1.99 now gets to the Win 2.0 splash screen but hangs after that; still, that's further than I've got for quite some time. The other app in question is Sound Globs, an excellent algorithmic MIDI composition program. I never got very far with SG under dosemu, the splash screen would appear then the app would just hang. Curiously, another app (Drummer) from the same company works beautifully under dosemu. However, I'm now able to open and run the program, but something happens when it opens that kills its MIDI activity. The program appears to be working, it just doesn't send any MIDI data. Upon opening it sends a big MIDI reset to my synths (including a big chord with no apparent note-off), then I get no joy. :( I'm still working with it though, trying to at least create some MIDI files for later use. Anyway, I'd like to send these apps to someone on the dosemu team for possible testing at your level. I sent M/pc to Stas quite some time ago, he said it worked for him (after hanging on to that Win 2.0 screen for a long time) but gave no other details. I'm not sure what I might attack in the dosemu configuration, so any and all advice will be vastly appreciated. I understand you're probably quite busy, so don't bother with a response if you've no time. But if possible please pass this message on to anyone you think could help me here. TIA! Best regards, Dave Phillips - 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: Kernel 2.6
On Mon, 6 Oct 2003, Stian Sletner wrote: Anyone had any luck running DOSEMU on kernel 2.6? I installed test6, getting coredumps as it loads. Any known trick, or should I disclose more info? DPMI crashes because DOSEMU makes assumptions about the CS and DS registers which changed in 2.6 because Linus added support for sysenter. This DOSEMU bug is presently only fixed in the CVS. Alternatively look at the patch here: http://sourceforge.net/mailarchive/forum.php?thread_id=3207814forum_id=8386 which also mentions a problem with vm86 (but that's a kernel issue). 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: The first dosemu-1.2.0 release candidate is available!
On Thu, 2 Oct 2003, Ralph Alvy wrote: ERROR: X: Unable to open font vgaERROR: , trying vga... ERROR: X: Unable to open font vgaERROR: , trying 9x15... Everything else seems to be working. Just can't get VGA working over here. I'm booting dosemu from an MSDOS directory that's installed in /usr/share/dosemu like this /usr/share/dosemu/msdos I can't reproduce your font problem. Please try the following: /usr/bin/xdosemu (explicitly use /usr/bin) if that doesn't give you the right font then try, *after* running xdosemu, some commands, like this /usr/bin/xdosemu xlsfonts -fn vga xset q and please let me know what the output is. 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: The first dosemu-1.2.0 release candidate is available!
On Wed, 1 Oct 2003, A. Alper ATICI wrote: Now that it's a test kernel, I'm not sure if this is a problem of dosemu or not, but one thing for sure is that it stops once dosemu exits. yes, I've seen this myself too. It's most likely not a DOSEMU problem but an in-kernel vm86 problem (xfree86 suffers too). Debug: sleeping function called from invalid context at include/asm/uaccess.h:473 in_atomic():0, irqs_disabled():1 Call Trace: [c011b15e] __might_sleep+0x9e/0xc0 [c010bdd0] save_v86_state+0x70/0x200 [c01095ce] work_notifysig_v86+0x6/0x14 [c010957b] syscall_call+0x7/0xb Some kernel developers are looking at this -- see http://lkml.org/lkml/2003/8/18/209 Another thing that is broken on 2.6.0test is DPMI. That's a DOSEMU problem and fixed in the CVS now (will be fixed in 1.2.0 proper). 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: The first dosemu-1.2.0 release candidate is available!
On Wed, 1 Oct 2003, Ged Haywood wrote: On Wed, 1 Oct 2003, Bart Oldeman wrote: Another thing that is broken on 2.6.0test is DPMI. That's a DOSEMU problem and fixed in the CVS now (will be fixed in 1.2.0 proper). No rush about this, but any idea when 1.2.0 will be out? I need DPMI to work but I can wait until the stable release. hopefully next weekend, there are some problems relating to the binaries (RPM/tarballs) to flush out but nothing fundamental -- well except for that kernel 2.6.0test problem but only a small and safe fix is required to fix 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: dosemu-1.1.0 help
On Wed, 1 Oct 2003, Serge Naggar wrote: Installed the new 1.1.9 but it seems to not see the operating system in both cases and the vga fonts when started with xdosemu. I rpm'ed the dosemu then used the dosemu-freedos...tgz and dosemu...tgz. Please state exactly what you did and what you saw on the screen. su rpm -i dosemu*.rpm exit xdosemu should work after a small qa session. Similarly the tarballs if you follow the instructions in README.bindist. Also try to run xdosemu -D+dD -o log that should make clear why dosemu couldn't find the DOS. Hmm I wonder, do you have any old /etc/dosemu.users and /etc/dosemu.conf files lying around? If yes, then try to rename or delete them. 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: The first dosemu-1.2.0 release candidate is available!
On Tue, 30 Sep 2003, A. Alper ATICI wrote: On Sun, Sep 28, 2003 at 11:21:04PM +0100, Bart Oldeman wrote: [...] Please let us know if there are any release critical bugs present -- regressions vs. 1.0.2.1, doesn't run at all, the RPM is braindead, or similar. Here's the first glitch from RPM, a path problem: Please enter the name of a directory which contains a bootable DOS [ENTER = the default /usr/share/dosemu/freedos] [] ' to confirm/continue: yes CONF aborted with: *** error: /usr/local/share/dosemu does not exist ... giving up. I think your RPM installation clashes with the one from make install. The first is in /usr, the second in /usr/local. can you check `which dosemu.bin` and remove it if it's /usr/local/bin/dosemu.bin? 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: The first dosemu-1.2.0 release candidate is available!
On Tue, 30 Sep 2003, Ralph Alvy wrote: Here's what I get after unpacking and running the 1.1.99.1 binary: --- [EMAIL PROTECTED] dosemu]$ ./xdosemu ./xdosemu: line 1: readlink: command not found ./xdosemu: line 285: cd: /../Xfonts: No such file or directory You do not have the DOSEMU vga font installed and are running remote X. You need to install the vga font on your _local_ Xserver. Look at the readme for details. For now we start with an fixed font, which does not display all national characters correctly. ... be warned ./xdosemu: line 375: /../bin/dosemu.bin: No such file or directory ./xdosemu: line 375: exec: /../bin/dosemu.bin: cannot execute: No such file or directory --- But there is definitely a ../bin/dosemu.bin there. Looks like the readlink utility isn't as standard as I assumed it to be -- newer distributions have it in coreutils (standard), Debain has had it for a long time ind debianutils, but other distributions would only have it as part of teTeX. What distribution are you using? try to replace the line BOOT_DIR_PATH=`readlink $HOME/.dosemu/drives/c`/.. in the shell script named dosemu with the line BOOT_DIR_PATH=`dirname $0` I'll think about a better workaround. 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: The first dosemu-1.2.0 release candidate is available!
On Tue, 30 Sep 2003, Robert Komar wrote:
this doesn't look like it will work if there is a space somewhere in
the path. If awk is available on every system, then how about this:
BOOT_DIR_PATH=`ls -l $HOME/.dosemu/drives/c | awk -F- '{ print $2 }'`/..
It uses - as the field separator instead of the space. On my system,
the last '/' isn't required (the contents of the link already have a
trailing slash), but I guess it doesn't hurt to leave it there.
but this won't work if there is - somewhere in $HOME ;)
How about
BOOT_DIR_PATH=`cd $HOME/.dosemu/drives ls -l c | sed 's/.* - //'`/..
in this case the source filename in ls won't have spaces.
That'll work as long as no user name or group name or month (in some
language) has - in it.
An extra readline binary would be another headache -- where to find it?
perl is another option, but IIRC not completely standard, at least I
received patches a while ago to remove perl dependencies.
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
The first dosemu-1.2.0 release candidate is available!
Hi, please have a look at http://www.dosemu.org/stable the version number is set to 1.1.99.1 (close to 1.2.0). Some notes: The -bin tarball and dosemu-freedos tarball (now updated to Beta9) work like they did for 1.0.2.1 Alternatively, all-in-one RPMs (including FreeDOS) are available. All the binaries are now dynamically linked and require glibc 2.2 (for instance RH 7.0 or newer, SuSE 7.2 or newer, and Debian 3.0 or newer should work) and X libraries. The built-in command shell (comcom) is no longer used by default; FreeCOM is used instead. For those of you who have followed development, the 1.2 branch was forked off version 1.1.5.3 and incorporates everything in 1.1.5.7 + some more, but without the more experimental LFN support, filename NLS translations, and bitmap fonts in text mode in xdosemu. Some of the changes that happened since 1.1.5.7 are: * mouse support in xterms and putty * better support for keys in terminals * new (hopefully clearer) layout of dosemu.conf * the xterm and xdosemu title bars now show the DOS command that is executed * fixes to work with NPTL (as present in Red Hat 9) * various DPMI fixes * fix copy/paste to xdosemu * updated various parts of the documentation (HOWTO, EMUfailure) -- yes, I'm aware they aren't high quality but at least they are no longer wrong and reflect the current DOSEMU. * fix Turkish keyboard I'll get a full list of user-visable changes (wrt DOSEMU 1.0) and an announcement ready for 1.2.0 proper. Please let us know if there are any release critical bugs present -- regressions vs. 1.0.2.1, doesn't run at all, the RPM is braindead, or similar. 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: Turkish vga font
On Fri, 26 Sep 2003, A. Alper ATICI wrote: Here's a cp857 font for xdosemu. You can use it by setting $_X_font to vgatr, also make sure you have the following lines set: $_layout = tr $_internal_char_set = cp857 To have it installed via the usual make install command, the file vga-cp857.bdf should reside under etc and the attached diff be applied. Thanks! One day I will probably collect some of the fonts that are floating around and make it into a seperate vgafonts archive; having them all in the main DOSEMU source would really make it a lot bigger. 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: compile error version 1.1.5, gcc 3.3.1
On Thu, 25 Sep 2003, Christian Fischer wrote: Am Mittwoch, 24. September 2003 23:53 schrieben Sie: these functions are supposed to be in libXext.so Check your Makefile.conf; it should say something like LIBS=-lXxf86vm -lXext -lX11 -lslang -lm -ldl perhaps LIBS=-lXext -lXxf86vm -lXext -lX11 -lslang -lm -ldl helps? In any case this doesn't appear to be a gcc problem. Bart it looks like LIBS=-lXxf86vm -lX11 -lslang -lm -ldl in my case LIBS=-lXxf86vm -lXext -lX11 -lslang -lm -ldl helps well, why LIBS=-lXxf86vm -lX11 -lslang -lm -ldl works on my gcc3.2.3-machine? I think you're just lucky on your gcc 3.2.3 machine -- perhaps -lXxf86vm or -lX11 automatically link the -Xext symbols. The configure script will use -lXext if mitshm is enabled. For some reason you're not using mitshm -- check config.log and the configure output. But the unlikely case of not wanting mitshm but wanting xf86vm (vidmode) should be handled anyway -- so the configure script needs to be fixed. 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: Approximation glitch in v1.1.5.7
On Mon, 22 Sep 2003, A. Alper ATICI wrote:
Now comes the next two problems I have not mentioned previously:
'(' is typed in place of '*' and
'=' is typed in place of '+'
Do you think that is related to the little flaw in approximations?
No. It's only a problem in terminals, (not in xdosemu), and can be solved
by editing src/plugin/term/keyb_slang.c.
remove these two lines
{*, KEY_8 | SHIFT_MASK },
{+, KEY_EQUALS | SHIFT_MASK },
I guess they are there to override the + and * from the numeric keypad,
but they are no longer necessary for US keyboards and are harmful for
Turkish keyboards!
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: Approximation glitch in v1.1.5.7
On Tue, 23 Sep 2003, A. Alper ATICI wrote:
OK, all seems to work now, provided that I set layout explicitly to tr,
otherwise (i.e. in auto mode) DOTLESS_I approximation is back in effect.
that might be the approx glitch I was talking about:
diff -u dosemu-1.1.99.1/src/plugin/kbd_unicode/serv_xlat.c
dosemu/src/plugin/kbd_unicode/serv_xlat.c
--- dosemu-1.1.99.1/src/plugin/kbd_unicode/serv_xlat.c Mon Jun 23 01:02:12 2003
+++ dosemu/src/plugin/kbd_unicode/serv_xlat.c Mon Sep 22 23:17:57 2003
@@ -703,7 +703,8 @@
return;
if ((charset-keys[symbol].key == NUM_VOID)
- (charset-keys[approximation].key != NUM_VOID)) {
+ (charset-keys[approximation].key != NUM_VOID)
+ (charset-keys[approximation].character ==
charset-keys[symbol].character)) {
/* Copy the code from the approximate symbol to the symbol */
charset-keys[symbol] = charset-keys[approximation];
}
(FWIW, I cannot use dosemu under tr_TR locale because autoexec.bat is
not parsed correctly in that case).
that's under comcom right? How do other command.com's do?
Another thing I'd like to ask is making use of hybrid latin console
fonts part of the kbd package. These are named with lat prefix (e.g.
lat5-12.psfu) and contain box drawing along with 8859-X characters. Is
it any more complicated than adding a new charset in extra_chars (say,
lat5.c) and using the registered charset as a new option for
external_char_set?
Not quite sure what you're looking at here. Essentially you need to tell
DOSEMU what font is used in $_external_charset. Possibly when SLang gets
proper UTF8 support (I don't mean the current hack that is in some
distributions and breaks DOSEMU, but slang 2.0), terminal characters can
be better supported. But right now DOSEMU can't do much, esp if the
terminal is remote. Perhaps the acs sequences could help for box drawing
characters.
In any case this is non-trivial, and not likely implemented soon (at least
not by me).
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: Approximation glitch in v1.1.5.7
On Sun, 21 Sep 2003, A. Alper ATICI wrote: U_SMALL_LETTER_DOTLESS_I is a legitimate iso-8859-9 character, yet there exists an approximation for it, so it cannot be typed. Could the related developer please remove it? I don't think that would be the right thing to do. Approximations are only used if no alternative is available in the real character set. Did you check what happens if you remove the U_SMALL_LETTER_DOTLESS_I approximation? As far as I know you'd get a question mark instead then which is also not what you want. Did you set $_external_charset to iso-8859-9 and $_internal_charset to a DOS character set that contains the dotless i, such as cp850 or cp857? Please run dosemu -dumb -input '\rexitemu\r' -D+vk -O 21 | grep charset to be sure about 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: Approximation glitch in v1.1.5.7
On Sun, 21 Sep 2003, A. Alper ATICI wrote: On Sun, Sep 21, 2003 at 08:11:35PM +0100, Bart Oldeman wrote: I don't think that would be the right thing to do. Approximations are only used if no alternative is available in the real character set. What do you mean by the real character set (in terms of the dosemurc options) ? What I mean is that in the unicode-character set conversion approximations should be used as a fallback. So if you use $_internal_charset=cp437 then the DOTLESS_I should become the approximation whereas if you use $_internal_charset=cp857 it should become the DOTLESS_I. Did you check what happens if you remove the U_SMALL_LETTER_DOTLESS_I approximation? As far as I know you'd get a question mark instead then which is also not what you want. Yes, it works after removal. Currently internal_char_set is set to cp857, external to iso-8859-9, layout to tr, term_char_set is default (this one gets set to latin1). Actually, DOTLESS_I was the only glitch, the other 8859-9-specific glyphs appear flawlessly. AFAICS, put_character_symbol() handles these via type_alt_num(). Without a latin5 setting for term_char_set, I wonder if this is working by chance or by design. This is by chance. The mistake is that the Turkish keymap contains cp857 codes. They should be replaced by Unicode, ie. 'q','w','e','r','t','y','u',141,'o','p',167,129,13,U_VOID, should be 'q','w','e','r','t','y','u',0x131,'o','p',0x11f,0xc7,13,U_VOID, and some other lines need to be changed too. I'm actually still looking at the approximation strategy, it might be a little broken but fixing the Turkish keymap at least fixes your problem. 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: win3.1 attempts :)
On Sat, 20 Sep 2003, Ryan Underwood wrote: One other thing to mention: if the installation is aborted by selecting an Exit installation or whatever button in the windows portion of the setup; upon returning to DOS, there is some sort of fatal memory error in only FreeDOS (DR-DOS and MSDOS are fine): Invalid Opcode at 7272 E8DF 3293 EC83 0397 0A7E 7400 BE05 0001 02EB F631 CE81 10A2 I suppose this is a bug in FreeDOS but I thought it would be worth a mention anyhow. Again, like the GPF errors, this always remains the same, as long as you are using the same version of windows to test it. I sometimes forget that not everyone knows (because in the FreeDOS lists this topic comes up again and again without people checking the archives), but Windows 3.x is known not to work on FreeDOS. It just requires too much undocumented DOS that nobody bothered to implement so far. The problems with \system\... are probably caused by comcom? If you use freecom instead they should disappear. As for what Stas was referring to, I guess it was an existing Windows 3.x in native DOS. As for myself, I don't own Win 3.x so I can't even say anything really useful at all. 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: file lock() and share.exe
On Sat, 20 Sep 2003, John Charlton wrote:
void chkkbd(void)
{
int ch;
char str[80];
fprintf(stderr, Hit enter to continue, s to stop, q to quit
immediately...);
fgets(str, 80, stdin);
fputs(str, stderr);
ch = str[0];
if (ch == 's' || ch == 'S') {
bStop = TRUE;
}
if (ch == 'q' || ch == 'Q') {
bQuit = TRUE;
}
}
It is a pretty basic function. I did use getchar() at first, with the same
result. This function works as intended with kernel 1.1.26a (2026a) or in
linux. With kernel 2031 it behaves as described above and if you rerun the
same program it crashes the dosemu session.
Is there an earlier kernel I can use to solve the share/lock issue and not
introduce this stdin problem?
your problem looks like it might have been fixed in the upcoming kernel
2032. Please try and test http://freedos.sourceforge.net/kernel/kernel.zip
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: 1.0.2.1 and latest kernel?a [1.1.5.7 now]
On Thu, 18 Sep 2003, Ryan Underwood wrote:
Here is the procedure I undertook, to hopefully shed some more light:
1. First I added a new variable to the config struct in
src/include/emu.h called delay_interval
2. in src/base/init/lexer.l.in:
delay_interval RETURN(DELAY_INTERVAL);
3. in src/base/init/parser.y.in:
%token DELAY_INTERVAL
4. in src/base/init/parser.y.in also:
| DELAY_INTERVAL expression
{
c_printf(Hello, this is delay_interval speaking\n);
}
5. in global.conf, under checkuservar, I add $_delay_interval.
In the parser_version_3 scope, I add:
delay_interval $_delay_intervala
6. in dosemu.conf on my system, I add $_delay_interval = (1234)
7. I run the new dosemu.bin -D+C, and my c_printf is never displayed.
Any ideas?
sounds about right; maybe there's something obscure. Try a warn in
global.conf, and the options
-h2 -D+cw -O
(not -D+C but small c) for some more clues. Also _delay_interval should
show up in unix set and system set typed from the DOS prompt.
The difference between () and is in global.conf. Numbers from ()
you can add, multiply, compare and so on; on strings you can use strlen
and so on. See also README-tech.txt.
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: 1.0.2.1 and latest kernel?a [1.1.5.7 now]
On Thu, 18 Sep 2003, Ryan Underwood wrote: On Tue, Sep 16, 2003 at 04:33:50AM -0500, Ryan Underwood wrote: While on the topic, is there a document that explains how to add a new configuration option? I have modified, parser.y, config.c, global.conf, and lexer.l and having a little trouble getting the new variable to be seen. I grepped through the docs for lexer and parser but didn't see much useful right away. I take it from lack of response that nobody knows? :) Just kidding, but I really have some problems implementing a new configuration option, so any hints would be helpful. have a look at a small prepatch that does exactly that, eg. patch-1.1.5.5 added a $_lfn_support option. 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: file lock() and share.exe
On Thu, 11 Sep 2003, John Charlton wrote: I have a dos application compiled with djgpp compiler in dosemu. A call to the lock() function which works in native freedos (beta 8) always returns -1 (failed) in dosemu. I first used dosemu 1.0.2.0 which installs with SuSE Linux 8.2 distribution. I just installed dosemu-1.1.5 and observe the exact same behavior. The freedos version used with dosemu-1.1.5 is: FreeDOS kernel version 1.1.24c (Build 2024c) [Jun 10 2001 22:25:01] you'll need to upgrade your freedos kernel. Replace your kernel.sys with v. 2031 at http://freedos.sourceforge.net (fat16/32 doesn't matter). Beware of unzip and uppercase: use unzip -L otherwise you end up with KERNEL.SYS and kernel.sys. share.exe has absolutely no effect on the network drives (from lredir) that DOSEMU uses by default. 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: Three major questions.
On Sat, 6 Sep 2003, administrator wrote:
I am running dosemu 1.1.5.6 and would like to see if it is possible.
1) To get rid splash screen Now type ENTER to start DOSEMU and
automatically start dosemu without hitting a key.
I will second this request.
-quiet should take you straight to the prompt
I wonder why it's not working for you two. dosemu and xdosemu create files
~/.dosemu/stamp-[x]dosemu the first time which prevent the splash message
being shown for all subsequent DOSEMU runs. At least, they do for me.
Have a look at `which dosemu`. There should be lines such as
if [ -z $QUIET -a ! -f $HOME/.dosemu/stamp-xdosemu ]; then
2) Running a dos program directly from the linux prompt and exiting back
into linux after it is done.
You can do this with a simple bash script if we can take care of
problem number 1 above and 4 below.
dosemu [-E] dos-command; see man dosemu.bin or the example in man
dosemu. Alternatively use -input
4)
Which brings me to my own issue with dosemu the -U switch
dosemu -U pipein:pipeoutdoes not work.
Dosemu will take whatever command you send to pipein and
pushes 'Command whatever not found' out pipeout.
If anyone has ever gotten pipein to work correctly, please provide the
version number of the functional dosemu and any undocumented
steps required to make it work.
-U is a programmer's tool; not so much a user's tool
This option should therefor only used by frontends (such as kdos),
which first create the proper named pipes and then launch DOSEMU.
A tiny control terminal, which can serve as example, is the supplied
dosctrl programm.
Well kdos (KDE DOSEMU) never really became something I guess, but
dosctrl
dosctrl is in src/tools/periph
so this works
$ cd src/tools/periph
$ mkfifo fdin fdout
$ xdosemu -Ufdin:fdout
$ ./dosctrl fdin fdout
help
ack [{on|off}] get/set user hook handshake acknowledge
hello just for testing, any kinf of argument
killkill the dosemu session from inside
version prints the dosemu version
keystroke strokes insert keystrokes into the DOS session
log [debugflags]get/set debugflags which control log output
hog [value] get/set the HogThreshold
boot [{on|off}] get/set the mode of the vbootfloppy
xmode [args] set X parameters, without args gives help
lredir n: dir [ro] redirect directory 'dir' to DOS drive 'n:'
helpthis screen
ecpu [{on|off}] get/set cpuemu
config print the current configuration
version
dosemu-1.1.5.7
^C
$
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: Three major questions. issue one
On Sat, 6 Sep 2003, administrator wrote: where would the drive D come from? it wants to map ~HOME yes, I know, but this message was only in older DOSEMUs. The message you refer to is no longer in DOSEMU 1.1.5.6. It looks like you are accidentally using an older version of the dosemu script than the one from 1.1.5.6 you said you are using. try $ which dosemu it should say something like /usr/local/bin/dosemu It says:/usr/bin/local which dosemu *cannot* say /usr/bin/local Please be more verbose. What does dosemu *exactly* say to you? blabla doesn't help me (or you for that matter). If in doubt, re-run 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: DOS4GW / DOS32A programs
On Tue, 2 Sep 2003, Sylvain Petreolle wrote: Hi Uwe and others,I want to run DOS4GW intros / party demos under Linux.Since the Wine support isnt complete now with DOS32A,I tried to run it under Dosemu.Using the 1.1.5 dosemu sources, I get a segfault using dos4gw or dos32a.2 questions :- since the CVS repository is unreachable at sourceforge (cant log into the server), can someone provide a link to a mirror ?- has someone kind of success with these programs ? I guess you use Red Hat 9? it'll most likely work if you try 1.1.5.7 (see http://www.dosemu.org/testing/patchset-1.1.5.7.tgz) This uses an export LD_ASSUME_KERNEL=2.2.5 workaround though. Even better would be if you could test the two patches at: http://sourceforge.net/tracker/index.php?func=detailaid=795147group_id=49784atid=457447 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: DOS4GW / DOS32A programs
On Wed, 3 Sep 2003, Sylvain Petreolle wrote: I didnt even think that we would have the same problem with Dosemu and Wine (duh!) I guess you use Red Hat 9? it'll most likely work if you try 1.1.5.7 (see http://www.dosemu.org/testing/patchset-1.1.5.7.tgz) Sure, must the 2 patches be applied together ? yes, first 1.1.5.7, then fixnptl.diff and then nptl2.diff (but WITHOUT the LD_ASSUME_KERNEL trick -- we want to avoid that workaround). With LD_ASSUME_KERNEL=2.2.5 even plain 1.1.5 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: Bug in DOSemu-FreeDOS-bin?
Hi all, Hi Claudia, On Tue, 19 Aug 2003, Claudia Neumann wrote: doesn't really matter -- but please try to replace your kernel.sys with the newest version (2031, fat32 or fat16 doesn't matter) and see if that helps. See http://freedos.sourceforge.net. It's the same with the new kernel ke2031_32.zip. I played a bit with the program. I found: in the program you have to define the directory for the programm infdbf.exe. As default it says: c:\info\ with MS-DOS 7.1 the program finds the infdbf.exe, in FreeDOS it only finds the infdbf.exe, if I define the directory as: c:\info (without Backslash). Okay, you could say define it as c:\info, but if I define it at program-startup as c:\info the program doesn't find it eiter. May be it is a MS-DOS 7.1-bug? possibly, but it might also be a bug in the MFS (Mach File System, aka what lredir gives you) in DOSEMU. If you have any problems on the command prompt with FreeDOS then first try to use FreeCOM (the command.com that is also in the above mentioned .zip) instead of the default comcom. The plan is to deprecate comcom anyway. If there are still problems then, well you have 4 combinations: c:\info + MSDOS c:\info\ + MSDOS c:\info + FreeDOS c:\info\ + MSDOS It's probably possible to solve the bug if you mail me (not the list) some debug output, i.e. the file log from [x]dosemu -D+dD -o log compressed with bzip2 for all the 4 combinations. 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.1.5.7 (was Re: dosemu 1.1.5.6)
On Fri, 25 Jul 2003, Eemeli Kantola wrote: If you under win9x or unix create a text file containing intl chars, they appear incorrectly under dos edit, for example. This has something to do with font differences between dos and windows/unix, but is anyway the preferred behavior. However, windows somehow converts chars in file names somehow that they look the same under dos and windows. Dosemu seems to know nothing about that: as an example, a file named cliché is shown as clichtheta (where theta is a single greek theta) under dosemu. right so this problem surfaced in 1.1.5.6 since the vfat kernel driver translates from codepage xxx (default=437) to codepage iso8859-1 and 1.1.5.6 (on VFAT) doesn't mangle short filenames. Well it turned out that this easy approach (no mangling at all on VFAT) wasn't feasible in all cases and that with the unicode infrastructure already there in several places it was not that hard to translate filenames from the UNIX to the DOS character set now. In my testings (and Stas' for Cyrillic) it all works so I've put up 1.1.5.7 at http://www.dosemu.org/testing to ask for wider testing. We'll try to fix the LD_ASSUME_KERNEL and RH 9 issues for 1.1.5.8. Also in 1.1.5.7: * should fix the attribute (color) problems reported by Bernhard Bialas * DPMI was improved at several places; now it runs Windows 3.1 with os2win31.zip again. * some smaller fixes Bart - To unsubscribe from this list: send the line unsubscribe linux-msdos in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: uppercase filenames
On Wed, 13 Aug 2003, Ryan Underwood wrote: On Tue, Aug 12, 2003 at 08:43:34PM -0300, Alejandro Néstor Vargas wrote: I've just installed dosemu-1.1.5.6, it's workign right but in some cases the files created by the dos are created as uppercase in the linux filesystem. In particular, I can create directories with md and they are created as lowercase, but if I uses mkdir form a Turbo Pascal program, it is created as uppercase. The same occurs from inside the ide of Turbo Pascal: the files (source codes) are created as uppercase. I searched for a configuration for this but I coudn't find any reference of this. If you are using a lredir drive, the relevant code is in dosext/mfs/mfs.c, in dos_fs_redirect(). It looks like the file is created verbatim to the DOS create command; if the DOS programmer happened to use all uppercase or some mixed case in his program, the file is actually created with that case on the unix side, even though on the dos side it is all treated as universal case. The DOS (non-LFN) create command always passes pure upper case to DOSEMU (via int2f/ax=11xx). This used to be lowercased by some function in mfs.c so that a lower case file was created. However by introducing LFN support some MFS functions had to be changed to preserve case and hence some strlowerDOS calls were removed. Now the strlowerDOS happens at a later time but I think I forgot it for some cases. I agree that having mixed case filenames under unix tends to be an annoyance. Perhaps this should be made into a configurable option. It isn't mixed case that is a problem. LFNs preserve case by design, that shouldn't be configurable. The thing that is arbitrary is whether DOS SFNs are pure uppercase or pure lowercase in the Linux filesystem. To be consistent with the view the msdos and vfat filesystems give us they were always created lowercase in DOSEMU. Samba has these options (as a comparison): a) mangle case = yes/no controls if names that have characters that aren't of the default case are mangled. For example, if this is yes then a name like Mail would be mangled. Default no. b) case sensitive = yes/no controls whether filenames are case sensitive. If they aren't then Samba must do a filename search and match on passed names. Default no. c) default case = upper/lower controls what the default case is for new filenames. Default lower. d) preserve case = yes/no controls if new files are created with the case that the client passes, or if they are forced to be the default case. Default Yes. e) short preserve case = yes/no controls if new files which conform to 8.3 syntax, that is all in upper case and of suitable length, are created upper case, or if they are forced to be the default case. This option can be use with preserve case = yes to permit long filenames to retain their case, while short names are lowered. Default Yes. DOSEMU now uses a) no b) no c) lower d) yes e) no (but broken) I'm not sure which of these options make sense for DOSEMU -- DOS apps really expect case insensitivity so perhaps b)=yes is useless. 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: RE : ASCII in DOSEMU
On Thu, 14 Aug 2003, deden purnamahadi wrote: I tried but it still didn't work. I have a clipper application with some ASCII characters to create a box. When I run the application, the characters are replayed with ? , and then the appliction exits. I tried another clipper application with no special ASCII characters, and it runs perfectly. Attached is the dosemu configuration #$_external_char_set = cp437 #$_internal_char_set = cp437 you have to remove the #'s. Otherwise these two are treated as comments. Alternatively you could run 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: uppercase filenames: the problem is in rename
On Wed, 13 Aug 2003, Alejandro Néstor Vargas wrote: On Wed, 13 Aug 2003 12:05:46 +0100 (BST), Bart Oldeman [EMAIL PROTECTED] wrote: it's most likely a bug that was introduced in 1.1.5.5. I will investigate and post a fix later. I was creating a test program and discovered that the problem is when you rename a file. The test programs are in right, a fix for rename is this: --- src/dosext/mfs/mfs.c~ Wed Aug 13 21:29:51 2003 +++ src/dosext/mfs/mfs.cWed Aug 13 21:49:55 2003 @@ -3263,6 +3263,7 @@ bs_pos = strrchr(fpath, '/'); if (bs_pos == NULL) bs_pos = fpath; +strlowerDOS(bs_pos); strcpy(buf, bs_pos); *bs_pos = EOS; find_file(fpath, st); Not sure about mkdir though -- reading the source I'm convinced that it should create the directory in lower case... 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: uppercase filenames
On Tue, 12 Aug 2003, Alejandro Néstor Vargas wrote: I've just installed dosemu-1.1.5.6, it's workign right but in some cases the files created by the dos are created as uppercase in the linux filesystem. In particular, I can create directories with md and they are created as lowercase, but if I uses mkdir form a Turbo Pascal program, it is created as uppercase. The same occurs from inside the ide of Turbo Pascal: the files (source codes) are created as uppercase. I searched for a configuration for this but I coudn't find any reference of this. ¿Anybody can sugest me a solution or a walk-arround for this problem? it's most likely a bug that was introduced in 1.1.5.5. I will investigate and post a fix later. 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: root can't access files?
On Sun, 3 Aug 2003, Ryan Underwood wrote: Okay, I figured out what is going on. I have a daemon (BBS server) that is spawned from an init script, and when a user accesses a DOS program in the BBS, it forks off DOSEMU to redirect the comport I/O to the user. The problem occurs when: 1) The daemon is run with root privileges 2) The daemon's init script is run through a `sudo`. The latter is common since the sysop might use sudo to either restart the BBS, or to apt-get upgrade (which will restart the daemon as part of its process). DOSEMU checks to the real uid, drops privileges to the real uid, and then can no longer access the files which have root permissions. This is a way to avoid suid-root on dosemu.bin and let sudo manage much of the security that used to be done by dosemu.users settings. Sudo is much more reliable than DOSEMU security wise (better audits and so on). Look at the file named INSTALL for a possible setup. So it fails starting the user's requested program for seemingly no reason. However, when done a `su - root` and then running the init script, there is no problem, since the real login is root that time. I explored various stupid hacks in the privilege code, but I just thought I would ask if anyone has a better idea how to use sudo with dosemu. This is a little bit of a pain! using it twice, like sudo sudo dosemu should work around it. The script user then needs to be able to gain absolute (unlimited) root using sudo however (i.e. able to run sudo bash), and not just the permission to execute dosemu.bin with 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
Re: Dosemu 1.1.5.5 color faults under X
On Fri, 18 Jul 2003, Bernhard Bialas wrote: with the new dosemu 1.1.5.5 version some of my chess programs show completly wrong colors under X (not in the console). So for example the menu text is yellow instead black, squares grey instead brown, figures green insteas white and so on. This behaviour happens with some (tested: 6) chess programs (Zarkov2, Chess Genius 5, Tascbase, Hiarcs 7, Chessmaster 3000). The other shows the colors right. Strange is, that with the version 1.1.5.2 no such faults occures (with the same dosemu.conf, no changes in X-related stuff). have a look at http://sourceforge.net/tracker/index.php?func=detailaid=628504group_id=49784atid=457447 the patch seq.diff solved a colour problem with Jazz Jackrabbit but might have caused your issue. Can you give it a try? Apply reversed using patch -p1 -R seq.diff 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: 1.1.5.5 compilation problems
On Wed, 16 Jul 2003, Justin Zygmont wrote:
[...]
checking for X... no
checking for XOpenDisplay in -lX11... no
checking for XCloseDisplay in -lX11... no
checking for main in -lXwindow... no
[...]
configure: WARNING:
configure: WARNING: Compiling without X support.
configure: WARNING: Install the X development libraries if you want support for X.
was that the intent -- do you never compile DOSEMU with X support (ie.
does 1.1.5 do the same here?)
That explains it though; a small guard is needed in int10.c, as follows:
--- src/base/bios/int10.c.~1.4.~Sun Jun 29 22:59:39 2003
+++ src/base/bios/int10.c Wed Jul 16 09:21:11 2003
@@ -723,6 +723,7 @@
/* helpers for font processing - [EMAIL PROTECTED] 11/2002 */
/* only for TEXT mode: Otherwise, int 0x43 is used... */
+#ifdef X_GRAPHICS
static void vga_RAM_to_RAM(unsigned height, unsigned char chr, unsigned count,
unsigned seg, unsigned ofs, int bank)
{
@@ -767,6 +768,7 @@
}
vga_RAM_to_RAM(height,0,256,seg,ofs,bank);
}
+#endif /* X_GRAPHICS */
/**/
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.1.5 Binaries?
On 14 Jul 2003, Peter Celella wrote: The IPC in the kernel thing is what has me confused. I've searched everywhere and can't find anything telling me what this is or how to check it. Do you know how to check if IPC is configured in the kernel? And if not, how to go about doing so? if the DOSEMU 1.0.2 binaries work then IPC is there; you're only difference is in the libc used (glibc 2.3 vs. libc5 and maybe dosemu.conf settings. If you run xdosemu then DOSEMU uses more IPC than without X (VGA memory). export LD_ASSUME_KERNEL=2.2.5 sometimes seems to do wonders on RH 9. Also check if you're low on disk space in /tmp or $TMPDIR -- if there is not enough shmmax memory for mapshm then DOSEMU creates a large file for mapfile. as to failed static linking you'd have to look at config.log, at the lines following XCloseDisplay. 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: running TCP?IP applications using WINSOCK in dosemu
On Sun, 13 Jul 2003, Madhumohan MuthuKrishnan wrote: I found some references in the readme. But it was for windows 3.1 and OS2 Is thre any one who has tried such applications WinOS2 should run but it's been a long time since somebody tried it and told me about it. I never did. Windows 95/98 don't run in DOSEMU -- you'd have to look at Wine, win4lin or vmware for example. 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.1.5 compile in X support?
On 13 Jul 2003, Peter Celella wrote: When I try to './configure', I get that the following output just before configuring finishes: configure: WARNING: configure: WARNING: Rejecting system S-Lang with UTF-8 support. It is incompatible with DOSEMU. Forcing use of the supplied S-Lang plugin. configure: WARNING: configure: WARNING: Compiling without X support. configure: WARNING: Install the X development libraries if you want support for X. I don't get this. If I have ALL the Redhat 9 X development packages installed, shouldn't the necessary libraries be in place? If not, what do I need to install that isn't already there? look at the configure output; it should say something like: checking for X... libraries /usr/X11R6/lib, headers /usr/X11R6/include also look in config.log for clues. the relevant RPM is something like XFree86-devel /usr/X11R6/include/X11/X.h and /usr/X11R6/lib/libX11.a should exist 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.1.5 compile in X support?
On 13 Jul 2003, Peter Celella wrote: I did get dosemu to compile by setting linkstatic off. isn't it that by default now? Now I'm getting that IPC error that I don't know what to do with. BTW - the X.h and libX11.a files you mention below do exist in the proper directories on my system. What I don't get is why I'm told X won't be compiled in when I use linkstatic on. apparently with linkstatic some more libraries need to be linked in. But I don't know which ones; this seems to be RH specific. config.log should have the details in the lines following checking for XCloseDisplay in -lX11 I don't know what do with that IPC error 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: App database, libsynth
On Sat, 12 Jul 2003, Jan Willem Stumpel wrote: So how about pasting the code directly from dosbox? I wish I could do it myself but I lack the skill... it's never that easy :) One uses C++ the other C and the strategies are a little different (because we partly emulate the CPU and partly look for dirty memory pages whereas dosbox completely emulates the CPU). It just makes for another reference apart from vgadoc and RBIL and so on. Just like the DosBox people say in THANKS: Vlad R. of the vdmsound project for excellent sound blaster info. Tatsuyuki Satoh of the Mame Team for making an excellent FM emulator. Jarek Burczynski for the new OPL emulator. The Bochs and DOSemu projects which I used for information. Freedos for ideas in making my shell. 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: [RFC] dosemu config generator
On Sat, 12 Jul 2003, Ryan Underwood wrote: .dosemu/.dosemurc is the same format as /etc/dosemu/dosemu.conf correct? It's just ~/.dosemurc everything can be configured there except for some privileged settings (most notably $_ports and console graphics), so becoming root to edit dosemu.conf is rarely necessary. in the setup directory there are probably still some references to ~/.dosrc. This is an old style per user config file (pre 0.97) which has the same syntax as global.conf and is obsolete. 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: App database, libsynth
On Fri, 11 Jul 2003, Ryan Underwood wrote: You may be right that people are stuck with OSS drivers that only support 1 stream and have no FM device. I don't see a way to deal with this at the moment. Though you would be hard pressed to find a soundcard that didn't have an ALSA driver these days. And, c-media PCI cards have an opl3 onboard and cost something like $5. :) I just keep wondering about the FM devices. The DOSBOX people seem to have been able to get that working, so what is special about DOSBOX that is so difficult in DOSEMU? I was wondering btw: http://www.happypenguin.org/show?DOSbox http://www.happypenguin.org/show?DOSboxstart=10 the opinions here are really different (no I didn't contribute but I'm wondering who did)... I only recently had a look at DOSBOX -- they really want games and games only; the builtin DOS doesn't worry at all about undocumented DOS stuff and backspace doesn't work very well in DEBUG. But then I may be a little biased. In any case whatever works better in DOSBOX (e.g. parts of VGAEMU still I think) can be looked up in the source code; they thank DOSEMU too. replacement for coopthreads is already in CVS, but the complete removal of coopthreads will require also removing comcom.com, so the coopthreads is still there. just to clarify, it's still there but it's dead code as long as you don't use comcom. Before it was always initialized. There is always the possibility to port to a non-linux platform but I think it will take untying it from the x86 hardware to get more people interested in dosemu long-term. agreed. And QEMU will probably stand a better chance now than Alberto's simx86 since some very capable people work at it and Alberto doesn't seem to have time for simx86 anymore. Right now QEMU also emulates DOSEMU itself which is a little strange however. One interesting platform is AMD's x86-64 (hammer, opteron, or whatever it's called today). Linux for x86-64 does have modify_ldt but no v86. That means that a potential future DOSEMU for it has to run real mode 16bit apps emulated but can execute DPMI apps natively. http://holarse.wue.de/?content=emu_dosemu has an interesting opinion too: Fazit: Auch wenn Dosbox bereits einiges leistet, kann er auch im Spielebereich Dosemu noch nicht ersetzten. Beide haben vor und Nachteile. Bei Dosemu stört sicher am meisten, das er auf Linux/x86 beschränkt ist. An Dosbox vermisst man dagegen den Fehlenden Protectedmode sehr. Es ist also sicher am besten, beide zu probieren und für jede Aufgabe den zu wählen, der sie am besten bewältigt. rough translation: Result: Even if DOSBox already really accomplishes something, it cannot really replace DOSEMU for games. Both have adavantages and disadvantages. With DOSEMU it's most annoying that it is restricted to Linux/x86. With Dosbox one misses protected mode a lot. It is certainly best to try both and to decide which one to use on a case by case basis. 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: Remote X
On Thu, 10 Jul 2003, Anderson Pereira Ataides wrote: I tried to run xdosemu on a workstation that is accessing a remote X server and I get this error: X Error of failed request: BadAccess (attempt to access private resource denied ) Major opcode of failed request: 144 (MIT-SHM) Minor opcode of failed request: 1 (X_ShmAttach) Serial number of failed request: 75 Current serial number in output stream: 76 What should I do to solve this problem??? try $_X_mitshm=(off) in ~/.dosemurc or 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: some problems (1.1.5 and 1.1.4)
On Tue, 1 Jul 2003, Will Styles wrote:
--- Justin Zygmont [EMAIL PROTECTED] wrote:
i'll try. however when I managed to try again with 1.1.4, the problem was
there, just not quite as bad.
well the patchset number is really critical here...
So I don't know if it'll make much
difference if it was like that all along.
i'm not concerned with persistent problems.
i'm more concerned about this: if the situation gets *drastically* worse from
1.1.4.9 to 1.1.4.10, i know what the problem is. so i am most interested in
these 2 revisions.
hmm what would be the problem in 1.1.4.10? I can see
+ - allow DSP commands in high speed mode (fixed problem with
+ Pinball Dreams 2)
@@ -754,7 +753,7 @@
case 0x0C: /* dsp write register */
if (SB_dsp.dma_mode HIGH_SPEED_DMA) {
S_printf(SB: Commands are not permitted in High-Speed DMA mode!\n);
- break;
+ /* break; */
}
sb_dsp_write ( value );
break;
Does this change make all the difference for you? Funny...
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: 1.1.5 compile and xdosemu
On Sat, 28 Jun 2003, Justin Zygmont wrote: On Sat, 28 Jun 2003, Ralph Alvy wrote: I compiled and installed 1.1.5 and find that this process fails to produce an xdosemu executable. Tried it twice and only got the dosemu exectuable. Is that normal behaviour, even though I am using the default config settings files (which has X on)? Should I just copy my copy of xdosemu from my 1.0.2.1 installation into the /usr/local/bin? of course not, they're different versions. Didn;t you see the xdosemu file? it's a symbolic link to dosemu.bin no it's a symbolic link to dosemu. Make install should produce something like the following: ls -l /usr/local/bin/dos* /usr/local/bin/xdos* -rwxr-xr-x1 root root27698 Jun 29 11:41 /usr/local/bin/dosdebug -rwxr-xr-x1 root root10339 Jun 29 11:41 /usr/local/bin/dosemu -rwxr-xr-x1 root root 3827798 Jun 29 11:41 /usr/local/bin/dosemu.bin lrwxrwxrwx1 root root6 Jun 29 11:41 /usr/local/bin/xdosemu - dosemu xdosemu is an alias for dosemu -X. 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: 1.1.5 compile and xdosemu
On Sun, 29 Jun 2003, Ralph Alvy wrote: Thanks for taking the time on all this, Bart. I'm obviously not a sophisticated Linux or dosemu user. DOSEMU always had a bit of a reputation that it was difficult to set up and I'm trying to make that a little easier -- so this kind of feedback always helps (to see where the rough edges are). That said, I now have 1.1.5 working with xdosemu. But I find that a certain setting that allows one of my apps to work under 1.0.2.1 is missing from dosemu.conf. That's the $_kbint setting. I had to set that to off in 1.0.2.1 to allow a particular app to work properly. I think I can work around this, but was wondering if this setting is going to return in a future version of dosemu.conf. keybint is always on now. It should be, because it is also always on in a real mode PC 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: Shift Tab not working in dosemu 1.0.2.1
On Sat, 28 Jun 2003, Ralph Alvy wrote: mrvoland wrote: I'm running dosemu 1.0.2.1 under RedHat 8, using MSDOS as my dos environment. I notice that Shift Tab doesn't work in dosemu sessions. is there a way to make it work? /etc/dosemu/dosemu.conf $_rawkeyboard = (1) # bypass normal keyboard input, maybe dangerous Hmmm...tried this, but it fails. I also tried all combinations of $_rawkeyboard and $_kybint, but none allow for Shift Tab. these options are only effective on the console. If you're using dosemu then try xdosemu. For xdosemu you might want to try alt+shift+tab or some other combo, or configure your window manager so that it doesn't steal the key. 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: Shift Tab not working in dosemu 1.0.2.1
On Sat, 28 Jun 2003, Ralph Alvy wrote: Justin Zygmont wrote: if you cannot switch to a vitrual console, then testing this in X would be easier to close the window when it hangs, other than that, i'm not sure. Oh, I can switch out of the console with the hung dos app, but I can't logout of that console and then start again. Or at least I don't know how to. you'd have to switch to another vc, kill the dosemu from there and switch back. Or use Ctrl-6 c Ctrl-6 a PgDn (on a US keyboard) which simulates ctrl-alt-pgdn in terminal mode. Hit Ctrl-6 h for help. Note that in 1.0.2.1 (as opposed to 1.1.5) $_rawkeyboard does not work unless you are root or make dosemu.bin suid-root. In general at this stage it would be worth trying dosemu 1.1.5 if you encounter problems with 1.0.2.1. The shift-alt-f4 trick has nothing to do with the console, that's just for X. 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: boot.log (2)
On Fri, 27 Jun 2003, Jan Willem Stumpel wrote:
Found my missing boot.log by doing an strace:
strace -omytest -f -e trace=file dosemu
In mytest there is a line
594 open(/tmp/dosemu.qvalfr/boot.log,
O_WRONLY|O_CREAT|O_TRUNC|O_LARGEFILE, 0666) = 3
So boot.log is somewhere in /tmp, not in ~/.dosemu -- and it
*disappears* when (x)dosemu terminates. That's why I couldn't find
it; I can see it in another VC/xterm only while (x)dosemu is still
running.
Any idea what could cause this?
are you sure that you're not using Debian's dosemu script
(ie. /usr/bin/dosemu installed by Debian)? It does:
workdir=$(mktemp -u ${TMPDIR:-/tmp}/dosemu.XX | tr A-Z a-z)
...
LOG=$workdir/boot.log
which explains what you get. If you use DOSEMU 1.1.x you should be using
the supplied dosemu script (which make install puts in /usr/local/bin/ by
default)
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 (dosemu.org) - 1.0.2 - mouse and sound support
On Fri, 20 Jun 2003, Björn Tappert wrote: I have a problem with the mouse support. When I run System Shock (pc game, cool, isn't it?) in my dosbox, I can move the mouse and see the mouse spot moving correctly on screen. But if I press a button, you can see the mouse spot in upper left corner, so doesn't metter where I press an button, the Game always does whether I press it in left upper corner. Any Ideas? This is a known problem with certain window managers. There are three ways out a) try another window manager b) move the mouse a little bit whilst the button is pressed c) try dosemu 1.1.5 (it's still in development; not that it's unstable at the moment, it's just that we have 175 glitches (or so it seems...) to solve...). DOSEMU 1.1.5 solves your problem. Second Problem: How can I test whether the sound support is working correctly? Is there a test-program or sth. like that? Does anyone have ideas how to run SystemShock with sound? sound support is poor in 1.0.2 as well. Here a development version is the only way out. 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 as a regular user?
On Mon, 16 Jun 2003, Justin Zygmont wrote: I just noticed that I can compile and install dosemu as a regular user, I was just wondering if this was not supposed to be the case. It was sure nice getting 100% cpu power on a P-4 3Ghz, too bad it wouldn't send the sound over the internet too:) no problems with that; this is the reason for the conservative default hogthreshold -- if I set hogthreshold to 0 then my laptop fans will spin up quickly too. If you want to restrict user usage of the CPU then root will need to adjust some settings in /etc/security/limits.conf (or similar). 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 problems (1.1.5 and 1.1.4)
On Sat, 14 Jun 2003, Jan Willem Stumpel wrote: problem 1: 1.1.5 produces sound from the sound card in 'jill' and 'carmen sandiego', but not in Wolf3d; Wolfd3 hangs. This is with the defaults in dosemu.conf unchanged apart from the boot disk location. I haven't heard about any new problems with wolf3d yet, but i'll try to reproduce it. problem 2: Unfortunately I don't have my old dosemu versions any more. So wanting to test a older version I downloaded 1.1.4 from ftp://ftp.ibiblio.org/pub/Linux/system/emulators/dosemu . Typed 'make' to compile it; but the compilation failed with Sorry, a.out system detected, but we do no longer support it But I don't have an a.out system; I have support for a.out disabled in the kernel. this happens if you use gcc 3.3 or newer -- and it was fixed in dosemu 1.1.5. for 1.1.4 a quick and dirty fix is to edit base-configure and replace echo echo Sorry, a.out system detected, but we do no longer support it echo exit 1 by ELF=ELF=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: Dosemu won't load any other dos
On Thu, 12 Jun 2003, Johan Gill wrote: On Wed, Jun 11, 2003 at 03:53:56PM -0400, Justin Zygmont wrote: you don;t give very much information. My daughter needed a diaper change :) Anyway, 'everything' means suggestions 2,3,5 from Bart. I'll try the other solutions when I get the time. Hmm, I wonder why 2,3,5 did not work. DOSEMU might try to parse a different configuration file than the one you edited -- try to run: xdosemu -D+c -O and watch for things such as: CONF: opened include file /etc/dosemu/dosemu.conf CONF: closed include file /etc/dosemu/dosemu.conf CONF: opened include file /home/enbeo/.dosemurc CONF: closed include file /home/enbeo/.dosemurc device: /home/enbeo/dosemu/freedos type 4 h: -1 s: -1 t: -1 drive C: 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: slight problem compiling
On Thu, 12 Jun 2003, Jan Willem Stumpel wrote: Compiling 1.1.5 fails; I get messages like lex.yy.c: In function `yy_get_next_buffer': lex.yy.c:3789: error: `yy_current_buffer' undeclared (first use in this function) lex.yy.c:3789: error: (Each undeclared identifier is reported only once for each function it appears in.) lex.yy.c: At top level: lex.yy.c:4372: warning: no previous declaration for `yyget_lineno' I must confess I did some messing around (i.e. re-installing) with my system recently. What might I be missing? I guess that your version of flex is too new. This will be resolved in due time, but for now it's probably best to downgrade your flex to 2.5.4 (if i remember well you use Debian so you could try installing the flex .deb from debian-stable). 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: commands with path
On Thu, 12 Jun 2003, bbg wrote: The command interpreter does not execute commands with full path e.g. [drive:]\[path]\command ex: c:\app\app[.exe] or that does not work indeed. \app\app[.exe] this works for me. It looks like bin\app.exe is interpreted as bin \app.exe probably as a result of trying to get cd\bin working somewhere between DOSEMU 1.1.3 and 1.1.5. Is this a limitation of freedos or of the (internal to dosemu, as I remember) command interpreter? So, how can be this fixed? it appears that you can work around it by typing a space in front of the command. D:\SOURCE bin\ls.exe works but D:\SOURCEbin\ls.exe doesn't. or use another command.com. or fix the source in src/plugin/commands/comcom.c 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: Download Problem DOSEMU-1.1.5
On Sun, 8 Jun 2003, Ged Haywood wrote: On Sun, 8 Jun 2003, Claudia Neumann wrote: if it is a browser mistake, then Mozilla 1.2.1 has the same problem. It could easily be that, but I still think there's more to it than just the browser. I've used the same browser to download other .tgz files today with no problem. right, the problem is with some sourceforge mirrors, see http://sourceforge.net/tracker/?group_id=1atid=21func=detailaid=747229 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 divide by zero errors in 1.1.5
On Mon, 9 Jun 2003, Daniel Greenberg wrote: It turns out the divide-by-zero problem isn't really new, just new. That is, 1.1.4.15 has the problem, but 1.1.4.0 is fine. I picked something in the middle - 1.1.4.8 - and found that it too had the new divide-by-zero errors. A couple more downloads and compiles and I was able to isolate the introduction of the problem to 1.1.4.7. That is, 1.1.4.6 runs without the new divide-by-zero errors, while 1.1.4.7 runs with the errors. So apparently 1.1.4.7 was the first to introduce this problem. Thanks, that narrows it down a bit. I suspect that the initialization (which was shuffled around a little in 1.1.4.7) is the culprit, but I fail to see where. Can you make hexdumps of the area from 0:0 to 0:500 for both DOSEMU's (using DEBUG in DOS or using dosdebug with the d command) and see if there are any differences, beyond the timer (4 bytes at 0:46c) and the keyboard buffer (0:41a- - 0:43d)? 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 divide by zero errors in 1.1.5
On Sun, 8 Jun 2003, Daniel Greenberg wrote: Here is an interesting problem that shows itself in 1.1.5 and not in 1.1.4 or earlier versions of dosemu. can you check 1.1.4.15 (www.dosemu.org/testing) to see if it is new or really new? Certain programs (e.g., MSD.EXE, Word for Dos version 5.0) fail with a divide by zero error message at startup. (The error message comes from within the dos session - dosemu itself doesn't crash.) These programs started fine under previous versions of dosemu. What is strange is that I can avoid these divide by zero errors if I start and then exit certain other programs (e.g. paradox, edit, /dos/help, dosshell) before trying to start Word or MSD. Though I'm not certain, I suspect that when these other programs exit they are restoring the video mode in some beneficial manner. are you running DOSEMU on the console or in X (xdosemu)? if you run it on the console, does $_vbios_post make any 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: Download Problem DOSEMU-1.1.5
On Sat, 7 Jun 2003, Claudia Neumann wrote: I just tried to download dosemu-1.1.5.tgz from the mirror in Brussels and the mirror in Dublin. The download didn't stop at 2073 kb, but went on til I stopped it 5000 kb. Is there something wrong with the download procedure? Is the file bigger the 5000 kb? I'm on a modem now so I'm not too happy to test it completely but wget gives me this: wget http://belnet.dl.sourceforge.net/sourceforge/dosemu/dosemu-1.1.5.tgz --00:05:24-- http://belnet.dl.sourceforge.net/sourceforge/dosemu/dosemu-1.1.5.tgz = `dosemu-1.1.5.tgz' Connecting to belnet.dl.sourceforge.net:80... connected! HTTP request sent, awaiting response... 200 OK Length: 2,121,858 [application/x-tar-gz] This length is correct. 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: problems compiling dosemu in mdk9.1
On Thu, 5 Jun 2003, Diego Iastrubni wrote: : `sys_errlist' is deprecated; use `strerror' or `strerror_r' instead lib/libarch_linux_slang-elf.a(sldisply.o)(.text+0x72): In function `SLtt_flush_output': : undefined reference to `errno' These problems were fixed in recent test versions (and soon in 1.1.5) -- try http://www.dosemu.org/testing/patchset-1.1.4.15.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.1.5
DOSEMU 1.1.5 DOSEMU 1.1.5 is out. This is still a developer's release. Things may work fine for you (and do for me) but some things can break that were working in 1.0.x. An example is copying and pasting of multiple lines which still doesn't appear to work correctly in all cases. That said, a lot of things have improved since 1.0.2.1; we aim to fix the remaining regressions for 1.2.0. Please look at http://www.dosemu.org/bleeding for downloads. I thank all contributors and testers for their patches and input during the 1.1.4 test cycle; you all know who you are. some things that are new in 1.1.5 in comparison to version 1.1.4: - many bugs have been fixed. - compiles with gcc 3.3 and newer glibc's. - requires gcc/egcs = 2.91.66 / glibc 2.1.3 or higher. - added TUN/TAP support for networking (as a substitute for dosnet that does not require root). - added fullscreen support for X (use Ctrl-Alt-F to switch between windowed and fullscreen mode). - improved the CPU emulator for VGAEMU; some more games run in xdosemu now. - added a $_vbios_post option: DOSEMU can skip the VGA BIOS' post when it is run on the console. - added long file support for file locking. - use of ~/.dosemu/drives/* -- by default DOSEMU will look in ~/.dosemu/drives for boot directories, hard disk images and symbolic links to those. A symbolic link from ~/.dosemu/drives/c to your boot directory is a useful alternative to setting $_hdimage in dosemu.conf or ~/.dosemurc. - the dosemu script is more quiet and uses -home by default. - added ability to use a DOS command as a DOSEMU option (without -E). In that case exitemu happens automatically when the DOS command terminates. This requires a unix -e command in your autoexec.bat. - use async I/O: async I/O speeds up the I/O dramatically. performance of the packet driver is doubled. - improved security if DOSEMU is run suid-root or via sudo * DPMI is no longer inherently insecure because DOSEMU drops root privileges before booting the DOS (and forks a server to deal with some port I/O if necessary -- on the Linux console this is required for some video cards and if $_speaker=native). * DOSEMU can be run via sudo in the same way as suid-root (it will revert to the identity of the original user) -- therefore it is no longer necessary to install two seperate DOSEMUs suid-root and one non-suid-root copy for security. One non-suid-root copy is all you need if you use sudo. As a side-effect dosemu.users is no longer necessary; without a dosemu.users file DOSEMU will only use its root privileges if it is run on the Linux console. * partition access, mouse access (console only) and serial access are no longer automatically accomplished using root privileges but must be regulated via permissions on the relevant /dev/xxx devices. * Note that, as before, root permissions are in general not necessary if DOSEMU is run in a terminal or in X. Enjoy, Bart Oldeman - 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: problems compiling dosemu in mdk9.1
On Thu, 29 May 2003, Diego Iastrubni wrote: I am tring to compile dosemu, and got into problems. The system is mdk9.1: gcc 3.2.2 bison 1.35-3mdk byacc 1.9-13mdk dosemu dosemu-1.1.4 Here is the compile output make[2]: Leaving directory `/home/cuco/sources/1/dosemu-1.1.4/src/dosext/misc' make[2]: Entering directory `/home/cuco/sources/1/dosemu-1.1.4/src/base/init' yacc -v -do parser.c parser.y usage: yacc [-dlrtv] [-b file_prefix] [-p symbol_prefix] filename I don't know why it uses yacc and not bison (as it should) but you can try make YACC=bison as a workaround. 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: Debian packages of development versions?
Morten Bo Johansen wrote: about the line 496 problem If I comment them out then I can start dosemu. But it would be better if the error was corrected. Don't know how to do that myself, though. this list is archived and you can search the archives for a solution. 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: [fd-dev] Re: Clipper printing problem with FreeDOS: try this...
On Thu, 20 Mar 2003, Eric Auer wrote: Hi Norman, well, thank YOU. You found the versions of FreeDOS at which 1. File locking started to work better (2026) and 2. Clipper printing broke (2027). This will probably help the kernel experts to figure out WHY 1. and 2. did happen, and how to solve 2. - maybe all this even helps with figuring out the Clipper double locking problems... 1. is because file region locking was not implemented at all for network drives before kernel 2026. 2. I don't know. I've never used Clipper; but try to produce a log using dosemu -D+dD -o log using both FreeDOS kernel versions and watch the differences; that might reveal something. 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.1.4.15 for testing.
On Tue, 18 Mar 2003, Ged Haywood wrote: I hope you'll do something about the instructions for building it before you put it out as 1.1.5. It's very confusing because there's so much of it that's out of date and inconsistent. It doesn't need to be completely rewritten but if you put some up-to-date instructions in a file called INSTALL then people who are used to doing ./configure make make install will be more much comfortable. This is exactly what the file QuickStart is supposed to do -- please tell me what you want to have changed in QuickStart -- I may be blind but the instructions are up-to-date as far as I know. The build scripts seem to be very fragile, I changed the directories in the compiletime-options and although everything was supposed to be in my home directory the make install failed with permission problems unless I was root. Shouldn't be and I just tested it. You must clean the tree and recompile (and reconfigure) DOSEMU if you fiddle with the compiletime-settings though, but maybe a Makefile rule could be added to do that automatically. It asked me if it was OK to use /home/ged/dosemu and I said no, use /home/ged/src/dosemu and it said OK, then I'll use /home/ged/src/dosemu/dosemu so I tried to stop that. The script then had trouble because it had created ~/.dosemu but hadn't done other stuff that was needed. When finally I got it figured out it failed again because the symlinks in /usr/local/share/dosemu/freedos/dosemu already existed. I had to keep doing rm -rf on a few directories to get a build I was happy with. There are two things here you talk about and I can't quite follow you here (to be able to correct the problem I must be able to reproduce your problems and without telling exactly what you did that is very difficult). a) problems with 'make install' b) problems running dosemu for the first time. One problem with a symlink may be solved using: --- dosemu-1.1.4.15/src/arch/linux/Makefile.mainMon Mar 17 11:26:13 2003 +++ dosemu-1.1.4.16/src/arch/linux/Makefile.mainMon Mar 17 11:27:58 2003 @@ -273,8 +273,8 @@ $(INSTALL) -d $(DESTDIR)$(syshdimagedir)/drives; \ ln -s $(DESTDIR)$(dosemudir)/freedos $(DESTDIR)$(syshdimagedir)/drives/c; \ fi; \ - rmdir $(DESTDIR)$(syshdimagedir)/freedos/tmp; \ - ln -sf /tmp $(DESTDIR)$(syshdimagedir)/freedos/tmp; \ + rm -f $(DESTDIR)$(dosemudir)/freedos/tmp; \ + ln -sf /tmp $(DESTDIR)$(dosemudir)/freedos/tmp; \ fi $(INSTALL) -d $(DESTDIR)$(sysconfdir) if [ ! -f $(DESTDIR)$(sysconfdir)/dosemu.conf ]; then \ to the question: Going to install your private DOSEMU files into the directory $HOME/dosemu Enter an empty string to confirm, a new path, or \none\ (without the quotes) if you don't want this: you said you entered /home/ged/src/dosemu/ and then it uses /home/ged/src/dosemu/dosemu well the files are going into /home/ged/src/dosemu/, just with one more directory below it. I don't see why that would be a major problem? The reason why is that a tarfile (by default, /usr/local/share/dosemu/dosemu-freedos-bin.tgz) is untarred into this directory and the pathnames just happen to start with dosemu/ But is what you really mean that the install script could be clearer and say something like Going to install your private DOSEMU files into the directory $HOME/dosemu Enter an empty string to confirm, a new path, or \none\ (without the quotes) if you don't want this, example: /home/ged/src installs your private DOSEMU files into /home/ged/src/dosemu. ? It grumbled about not having freedos even though I'd set 'fdtarball none' in the compiletime-settings. Same thing here as a few lines above: fdtarball none only takes effect after you run configure again. Having said that once it did compile (2.4.19) it started and ran quite a few things fine, but the attached pager (LIST.COM) crashes dosemu very reliably under X on my system. I just tried it, it doesn't crash for me. Which DOS are you using in your DOSEMU? 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.1.4.15 for testing.
Hi, I've put a new patchset (1.1.4.15) at http://www.dosemu.org/testing if you were using 1.1.4.13 before then please check if this one fixes your compilation fixes, and also please let us know if there are any new problems -- if everything is fine then I'll make this one 1.1.5. 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.1.4.15 for testing.
On 15 Mar 2003, Stephen Lee wrote: On Sat, 2003-03-15 at 18:06, Bart Oldeman wrote: Hi, I've put a new patchset (1.1.4.15) at http://www.dosemu.org/testing if you were using 1.1.4.13 before then please check if this one fixes your compilation fixes, and also please let us know if there are any new problems -- if everything is fine then I'll make this one 1.1.5. No problems compiling under Redhat 7.2. However, as mentioned in another thread, numlock within xdosemu only works if numlock is off before starting xdosemu when displayed remotely via VNC. If the xdosemu session is displayed remotely to another X workstation without using VNC, the numlock problem does not occur. Based on brief testing, everything else seems to work fine with Foxpro2.6. I've never used VNC so I really cannot say much about this specific situation; it might be problematic for DOSEMU to ask for the numlock state via VNC, it might even be a VNC problem and not a DOSEMU problem. At least the workaround isn't hard. what you also could try: * set $_X_keycode=(0) in your .dosemurc or dosemu.conf or * run an X server on the Windows site such as Cygwin xfree86. 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.1.x and 1.1.4.13 bug (?) on CPUs faster than 2.0GHz
On Wed, 12 Mar 2003, Maurilio Longo wrote: I fear that cpu speed is inside a long int and this shoud explain why it happens, I'd like to know from someone who writes dosemu if this is true and how they plan to fix this. it's a multiplication that overflows from an int -- try this patch: --- dosemu-1.1.4.13/src/base/init/config.c Sat Feb 15 14:49:31 2003 +++ dosemu-1.1.4.14/src/base/init/config.c Wed Mar 12 14:38:28 2003 @@ -484,7 +484,7 @@ cdd[6]=0; sscanf(cdd,%d,df); /* speed division factor to get 1us from CPU clocks - for * details on fast division see timers.h */ - chz = (di * 100) + df; + chz = (di * 100LL) + df; /* speed division factor to get 1us from CPU clock */ config.cpu_spd = (LLF_US*100)/chz; - 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.1.x and 1.1.4.13 bug (?) on CPUs faster than 2.0GHz
On Wed, 12 Mar 2003, Stas Sergeev wrote: Bart Oldeman wrote: it's a multiplication that overflows from an int -- try this patch: The attached one might also be necessary to get the correct output. - warn (Linux kernel %d.%d.%d; CPU speed is %Ld Hz\n, + warn (Linux kernel %d.%d.%d; CPU speed is %lld Hz\n, This is good for C99 compliance (C99 only guarantees ll but doesn't do anything from the practical point of view) -- info libc `L' `ll' `q' Specifies that the argument is a `long long int'. (This type is an extension supported by the GNU C compiler. On systems that don't support extra-long integers, this is the same as `long int'.) The `q' modifier is another name for the same thing, which comes from 4.4 BSD; a `long long int' is sometimes called a quad `int'. Still it's good to use a standard approach whereever possible, so thanks, 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
