gcc, an pretty old version.
I am sure I posted the flags and maybe even the version a few times on this forum.
So some searching might reveal them.

Hi!

I think I am going to do a full GCC/Dev environment install on a linux machine or maybe just XAMPP it .vs. continuing messin' with MinGW. I also see that Watcom now has their C++ compiler out there for free. Been many years since I used Watcom but it used to produce better code than just about anything else at the time by a significant margin.

I fuddled a bit with VC++ 9's stuff last night and managed to produce a build that's a bit faster than the official release candidate, I just really dislike (dont understand why MS hasnt done something about it!) the runtime deployment issues of VC.

I have not looked at DOSBOX's actual code as of yet. Given its platform independence which clearly was a goal I assume there is nothing in it dealing with multiple core CPU's?

It would really be interesting to isolate cycle munching such as the video related I/O to use a core. Years (I mean years) back I coded a graphics kernel (brother and I) called BLEAM which creamed Fastgraf and numerous others in abilities/speed... Eventually became part of the Atari ST "ST Lightning" etc etc. Once we ported the assembler primitives to the 68K CPU's.

I worked for Atari, Sierra, EMI and others back when game codin' was fun. In fact our line segment code was given to Mike Abrash and ended up in Quake. Never saw a dime from it 😀

Course' back in the DOS Days much slews of code sat based atop the interrupt structure, not shielded from it as things are today with layers of crap atop more layers of crap.

While I dont have time to toy with such things right now if ya'll have some architectural diagrams etc. of DOSBOX (to save me from having to go, "Oh... thats how they did it!" (reverse engineering) I might enjoy playing about to partition "DB" for multi-core's. Without having a clue about DB's current architecture I have no idea how easy or difficult it might be. In reality if one looks at the Quad Core CPU's things could get very interesting!

Look forward to hearing from you.

Personally I got executables of DOSBox that were faster than the standard downloadable version when using VC++ Express 2010 and tweaking all the optimization options. The 2010 compiler produces noticeably faster executables than the 2008. The difference is more pronounced when using the interpretive cores than when using the dynamic core of DOSBox, though.

Also you can link the C++ runtime statically, should save you the technical hassles of deployment, though I have no idea whether there are any legal problems with that.

I don't think there are any problems with distributing MSVCRT100 statically linked, however, there's an interesting note about that here:
http://msdn.microsoft.com/en-us/library/ms235316.aspx

I was reading various threads on here and there were a few posts sometime ago stating that dosbox's stability was not as good w/ VC as w/ GCC.

Apparently there are only a handful of people on here that have bothered to toy with DB and VC in any form of serious fashion.

Can anyone make statement towards this?

I dont have to do what I am working on in VS as far as Dosbox's part of it is concerned anyways. The .NET stuff I do but thats essentially independent of DosBox.

Should I just trash bothering to play with VC 9.0 and just go direct to VS 2010? And again, any testament towards stability .vs. a GCC build?

Thanks!

in the past we had problems with VC.
I don't know of problems with new versions.

Unless I'm trying to help someone here with a game I have (not using the official release for that would kind of beat the point, wouldn't it), I use my DosBox built with VC2010 to play any game and haven't had any problems so far, as TeaRex pointed out, I find it faster too. The only problems I've had are present in the official release too: when the PC Speaker beeps the buffer doesn't go silent immediately and Dungeon Keeper won't work; other than that, it's fine.
The 2010 compiler is better than 9.0 all in all, as TeaRex stated, and the end result, at least in my experience, is faster than GCC: I wrote several programs using wxWidgets (in the name of portability) and the Mersenne-Twister algorithm (a nice, fast, pseudo-random generator) and, while they were fast when compiled with GCC (mingw, specifically) they were noticeably faster when compiled with VC2010. DosBox too...

bloodbat wrote:

The only problems I've had are present in the official release too: ... Dungeon Keeper won't work

Dungeon Keeper most definitely works in the official release.

I can only support what bloodbat has said: There was a time when I wouldn't have touched a Microsoft product even with a pair of pincers, but their newer compilers are quite good as regards performace of the compiled code, they beat even GCC 4.5 which is already quite a bit better than older GCC versions for most things I've tried it with. Though they have other things I don't like so much, such as lack of a >64bit long double type.

I didn't have any stability problems with the resulting DOSBox executable either, but then again the number of DOS games that I play more or less regularly isn't all that high - mostly the later Ultimas and early 3D shooters, with the odd 1980s adventure game thrown in once in a while.

ripsaw8080 wrote:

bloodbat wrote:

The only problems I've had are present in the official release too: ... Dungeon Keeper won't work

Dungeon Keeper most definitely works in the official release.

Not the Gold version...

DK Gold works fine for me. A problem that often occurs with the Gold version is not finding a volume label of "KDDISK1" from the disc, but I don't recall seeing a post from you about your specific problem, so can't advise better than that.

Hiya's....

I guess I'll give it a go w/ VS 2010 then rather than continuing on w/ 2008.

I'll download Watcom sometime this week and see what I can make happen with it, as I noted... Watcom C++ is now free and used to be a really good compiler, not sure if it still is.

Thanks for the info.

I dont exactly know where it would be or if I even still have it... But back when we'd authored up Bleam which as I noted was a graphics kernel (and more) which we'd licensed portions of to varied entities the low level prim's for the PC we did not code. Instead we'd bought this library which was just low-level assembler basic primitives for literally every video card that existed for the PC. Our higher level primitives were coded in asm, such as line segments, on and on.

I can do some searching about to see if its still in a box someplace if it'd be of use to the project. As I recall it was like 3 or 4 diskette's and we'd had some update diskettes as new cards released... This was all pre 3DFX etc. But as I said, had all the low level code in asm, draw a pixel, read a pixel, BITBLT, setting res modes, color's blah blah for each card and a wee bit of common interface code to it. If I remember correctly it supported about 100-150 different boards.

meowser wrote:

In fact our line segment code was given to Mike Abrash and ended up in Quake. Never saw a dime from it 😀

Elaborate (i.e. which file/function?)? I have a tough time believing this.

ripsaw8080 wrote:

DK Gold works fine for me. A problem that often occurs with the Gold version is not finding a volume label of "KDDISK1" from the disc, but I don't recall seeing a post from you about your specific problem, so can't advise better than that.

It's in the dosbox games forum...thing is I get a "Can't switch video mode" error.

Dungeon Keeper - Unable To Change Screen Resolution

Maybe misconfigured game or vesa/univbe problem.

Here's how I install and run DK Gold: default settings in DOSBox 0.74, mount a drive C:, mount the disc image as drive D:, install with SETUP.EXE to C:\KEEPER using the English language choice, choose SB16 and auto configuration, exit install, run the game, it works with no problems.

Bloodbat's screenshot of the install program shows missing text in its menu, a sign that something is not right... perhaps certain files are not found. The "Unable To Change Screen Resolution" error message is contained in DATA\TEXT.DAT, but don't know the conditions under which it might be displayed.

DK uses VESA mode 0x101 for its menu, and mode 0x100 for its main game screen when toggled to hi-res with Alt-R, which should not be a problem for DOSBox with machine=svga_s3. SDD/UNIVBE is not included with the game, and does not appear to be needed.

Funny thing is...the install program works right (but really slow) on a FreeDos virtual machine 😖

Maybe there are different versions of the game, or maybe you're using an image that has something odd about it. Are you mounting a CUE/BIN image with IMGMOUNT in DOSBox? A couple of things to try: 1) mount the image in Daemon Tools, MOUNT Daemon Tool's virtual drive in DOSBox, and install from that. 2) If you don't have Daemon Tools or don't want to install it, you can copy the entire directory structure of the CD into a folder on your HD and then mount the folder in DOSBox like "MOUNT D C:\DKGOLD -t cdrom -label KDDISK1" and install from that. It will be interesting to see if either of those work when IMGMOUNT does not.

Yeah, I'm mounting the .cue/bin pair...I'll try your other suggestions.

Fancy that! It does work, install and all if mounted within alcohol 120 and then using the virtual drive as the mount for DosBox.

Thanks 😀