Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - Jochen Schäfer

Pages: [1] 2 3 ... 8
Applications / Re: DOSBox Issue - STDCPP6?
« on: June 04, 2020, 01:05:01 pm »

I will upload the new package to my site and possibly to Hobbes, but first I have to figure some packaging problem out.

Bye Jochen

Applications / Re: DOSBox Issue - STDCPP6?
« on: May 27, 2020, 07:06:49 am »
Question: Don't you want to activate the touch option?
Is this an option in your installer package?

Applications / Re: DOSBox Issue - STDCPP6?
« on: May 27, 2020, 07:04:05 am »
Hi Jochen

Yes the [autoexec] statements work fine.

The problem is the extra commands not in dosbox.conf that then happen ie mounting the selected drive or folder as C:\>


Oh ok. I misuderstood. Do you have a example how the commands are called?

Applications / Re: DOSBox Issue - STDCPP6?
« on: May 26, 2020, 09:31:02 pm »
Here you go. I built a recent package. Only difference to upstream is some code that prevents a crash from a CTRL+F9 exit.
Can somebody please test the WPI package?

Applications / Re: DOSBox Issue - STDCPP6?
« on: May 26, 2020, 08:46:55 pm »
Hi Dave

I think I have found a minor problem with your DOSBox build or the support files used.

AS i do not have DOS/Win16 support installed I have been using DOSBox to provide DOS window/fullscreen ~Command Prompts for very occasional use.

This worked fine until DOSBox and libstdc++ (9.2.0-4) updates.

Now DOSBox fullscreen works OK but something is adding to the dosbox,conf when using DOSBox window.

This is the end of my dosbox.conf file:-

# Lines in this section will be run at startup.
mount e e:

Works fine for -fullscreen, used to work fine for window as well.

When I start a DOSBox window the above mount lines happen then some more commands appear from somewhere and this happens:-

Drive C is mounted as local directory "H:\Desktop\"



Using -conf to point to my dosbox.conf (which should be the default to use anyway) gives the same result.

As the above MOUNT C is not part of my dosbox.conf and only happens in window mode, not -when using -fullscreen, Is it a DOSBox problem?

Just to confuse the issue: If I start a DOSBox window from the XWorkplace Configuration Folder -> ~Command Prompts -> ~DOS Window all works as it should.

The problem with the unknown lines above only occurs when I Right Mouse Button click and select Command prompts -> DOS Window in which case wherever I have selected to open a DOS Window becomes the mount directory eg RMB on folder K:\Programs and open a DOS Window results in "K:\Programs" as the directory mounted as C:\> .

Having typed the above I am now wondering if it could be XWorkplace related...

Any Ideas?


I can't reproduce this problem with my new build. In window mode every command in [autoexec] is executed. Did you try to execute Dosbox from the shell without parameters?

Applications / Re: DOSBox Issue - STDCPP6?
« on: May 26, 2020, 09:09:39 am »
A reboot later, I was able to update everything.

Applications / Re: DOSBox Issue - STDCPP6?
« on: May 26, 2020, 08:50:09 am »
Good to send your patches upstream but you need a link on your page pointing to sourceforge as it took me a while to figure out.
Thanks for maintaining.
Correct. I didn't think that someone would want to compile it herself.
I will put a link on my page.

Applications / Re: DOSBox Issue - STDCPP6?
« on: May 25, 2020, 01:16:52 pm »
Does anyone of you have netlabs-exp activated. I can't upgrade to GCC 9, because a dependency is missing.

PS: Yes, I'll file a ticket, if I can't resolve this issue.

Applications / Re: DOSBox Issue - STDCPP6?
« on: May 25, 2020, 08:16:07 am »
Hi Andreas,
I just basically used the defaults for building, ran to create OS/2 configure, makefile-in's and such then
Code: [Select]
sh configure "LDFLAGS=-Zomf -Zmap -Zhigh-mem" LIBS=-lcx
Looking at the INSTALL file, I see these configure options,
        disables the dynamic x86 specific cpu core. Although it might be
        be a bit unstable, it can greatly improve the speed of dosbox on x86
        Please note that this option on x86 will result in a different
        dynamic/recompiling cpu core being compiled then the default.
        For more information see the option --disable-dynrec

        disables the recompiling cpu core. Currently x86 and x86_64 only.
        You can activate this core on x86 by disabling the dynamic-x86 core.
So it seems the recompiling variant is the default. I could easily build another binary with these options if requested. I guess after 16 years the recompiling option is mature, or perhaps the INSTALL file is not clear.
Other possible options include compiling with the debugger enabled, introduces a ncurses dependency. Using SDL-NET for modem and IPX support, SDL-SOUND to support mp3/ogg audio tracks on some diskimages.
Don't know if Jochen is still active, if not I can build whatever if you want to package it.
I'm sort of. I got distracted by some other projects and life in general. I will try to build a new package with Andreas great package scripts in next few days.

Applications / Re: DOSBox Issue - STDCPP6?
« on: May 25, 2020, 08:06:19 am »
Update about my build, seems here it is using SDL12.DLL in @unixroot\usr\local\lib, not the RPM installed one. They both have the same name and presumably the same exports so should be interchangable, but who knows until tested.
This is just the latest tarball from sourceforge that I built as I couldn't find the source that Josh used. Luckily he/someone seems to have got the OS/2 patches committed upstream.
As for downgrading libstdc++, so much is going to depend on it as it is a basic system type library that downgrading isn't advised.
Hi, I always use the DOSBOX official repo for new versions. When I had something to change, I sent a patch to the maintainers.
So, compiling the tarball / SVN version, is the correct thing to do.

Games / Re: Quarantine Gaming !! - Dev/Port Help
« on: April 01, 2020, 11:04:26 am »
The tricky part is setting up the various SDL libs, at least the ones built with OpenWatcom which seem a better choice then the ones installed by YUM/RPM
Why is that?

Programming / Re: How to build Seamonkey?
« on: January 13, 2020, 08:24:21 am »
Thanks for your help. I will try to go from here.

Programming / Re: How to build Seamonkey?
« on: January 12, 2020, 01:36:26 pm »
Oh, my. It makes no difference.
You know, I only want to establish a good build environment for autoconf/make ports. So I don't know whether, it is necessary to solve this problem. What do you think?

Programming / Re: How to build Seamonkey?
« on: January 11, 2020, 02:15:54 pm »
I did that. I re-auto(re)confed everything.
Now, it stops in libffi with an ended pipe. What now?

Programming / Re: How to build Seamonkey?
« on: January 10, 2020, 10:05:07 pm »
Hi Dave.

Actually, I got it running. Alas, the build stopped at not finding gtest_prod.h.
According to the internet, it belongs to Google Test. How do I go on?

Pages: [1] 2 3 ... 8