zbiggy wrote:

I was at VDMS before. This is dead project. The sources are at CVS. But not anyone can go on with development - the source code is junky. If you are so clever try to download them and compile in MSVC without changing sources. If everything compiles without errors let me know how you done that. Till now nobody on forum answered to question about correct compilation of VDMS. Since yesterday I am sitting and cleaning up sources of VDMS and have now working only modules part. This is not funny, such comment made me angry. The live is not so easy as it looks.

I did not mean that restarting VDMsound development would not require work.... But since you wanted primarily just sound emulator (you wrote this: "The only thing form dosbox I need is sound card emulation"), then it is far easier to start with something which went in that direction (VDMsound), than something quite different (DOSBOX).
If you want to build a better ship (better sound card emulator), then it is better to start modernizing older ship (VDMSound) than to rework a modern aitcraft to ship (DOSBOX). Just because it is more modern as aircraft, it does not mean that it will be a better ship/submarine/rocket whatever after rebuilding (and certainly not that it will be easier).
If you have trouble recompiling VDMSound, I can assure that making new VDMsound from DOSBOX would take far more work.

Mirek

You could start off using the last release version source code.

I do think Qbix,Mirekluza (and others)are right.The thread is about future and development,so the what for and not the how to or why.
Computers are a strange tool (not really speaking of the machine itself,but the way it is used) but are not the only one:automobiles is the other.
Thus,common people directly uses this two machines,knowing very little of them and dont really careying of the machine's rules,as long it works.
Does anybody - non-expert - like to have acess and control of more pieces of his automobile? No,and,if possible,just to think and care about the destination,not the travel.
When I turn on my computer I stay happy if I can only think in writing,in playing,in studying the data base and,so,I am allowed to forget that in the middle are a complex machine and a complex language.
As so,my best wish for the development of Dosbox is that it becomes so sofisticated inside that it looks easy.No need of configuration.Just turn on the machine and call the target program.
(I read today that some desires are far in the future;that gave me hope because was writen by the same people who says that a game with 15 years is very old).
Best regards,

I agree with fed1943.
But we need here to make a list of priorities. First of all Dosbox needs to be
FAST and RELIABLE. There's no way to avoid it. It's _not_ acceptable that
you need an 8 GHz cpu to make it work well, or that you need to switch
cpu/memory/video/whatever hundreds of option combinations in order to
make a specific program working (and eventually crash).

After that, devs can work to make it easy/intuitive/integrated/ergonomic/
expandible/autoupdatable/allthosefunnythings.

It's a natural law. When you build a car you first make sure that the engine
works well and only after you check the air conditioner!

At the moment, with my AMD 2GHz cpu I can't run smoothly my favourite
old games that my good old 486DX4 (no more of this earth) ran perfectly.

As with car production, the guy who usually adds the leather seats isn't the best at installing the lights.

kekko: It might not be acceptable to you that an 8GHz CPU is required to emulate to 200MHz system, but it may not be feasible to do significantly better and still maintain DOSBox's goal of being a cross-platform DOS emulator that emulates a variety of sound and video hardware.

Also, the reason that you have to change options around in DOSBox to get certain games to work is not DOSBox's fault, but rather the fault of the people who made the games: they assumed that the hardware that their games would be running on would fall within certain parameters (mostly based on what people had at the time). As a result, DOSBox needs to know what those parameters are in order to make the game "comfortable" with running inside of it. I think it's great that DOSBox gives users so many options, such as the ability to test out a game using a variety of different emulated video (e.g. hercules, cga, ega, vga) and sound (e.g. pc speaker, tandy, adlib, sound blaster, gus), and I would be disappointed (and surprised) if the developers decide at some point to remove some of that functionality. More likely, they'll encourage people to continue developing frontends and databases and FAQs and forums that guide people in the use of DOSBox.

I think it also needs to be said that getting games to work in DOSBox really isn't much harder than getting them to work on a real DOS machine. In fact, it's usually a whole heck of a lot easier than getting it to work on a modern machine running DOS.

I do agree that there is definitely a need to improve what's already in DOSBox before lots of new features are added though.

Just a question:

- What gain can be expected when you provide Binaries compiled for a special processor, say

Dosbox-i686, Dosbox for AMD and so on.

Is there a gain of speed?

In my opinion speed does not matter as much as compatibility. Compatibility can be improved by talkbacks, better debugging, better code documentation.

Compilatin from source it always the best solution.

The architecture of PC is about to change greatly, the breakthrough is almost there (Multi-Core, Virtualization …). As a result the architecture of the OS and applications will change too. We want to run the DOS applications on the future PCs, not just the today’s IBM-PCs. So the portability is the key for this project to achieve its aim. We must ensure things can be done first, and then done better.

Don’t you expect to run your DOS applications on cells or devices someday?

Multi-Core isn't a change of architecure. It's pretty much the same as sticking another warehouse on the same concrete slab that another warehouse is already using.

A clean, processor-optimized compile might bring a performance gain of a few percent. The question is: Who does the make files for the several processor-optimized development tools? A third party AMD special compiler won't eat Visual Studio configuration files.

Snover wrote:

I am personally rather perplexed by this removal of 16-bit code execution. Certainly we need to move away from 16-bit code (no new programs are running with 16-bit code), but I'm not sure why 16-bit support would be completely removed. I assume that this would mean that NTVDM/WOWEXEC would be completely gone; this also means that lots of older Windows games (any Windows Sierra game, for example) would be completely unusable under XP64. For what gain?

The AMD64 has two operation modes: legacy mode and long mode. Legacy mode is basically AMD32 compatability mode: no 64-bit, only 32 and 16. Long mode is the new operation mode, and offers 64-bit and 32-bit execution. 16-bit is no longer supported in long mode. So it's not a choice of M$ to no longer support legacy 16-bit applications.

See http://en.wikipedia.org/wiki/X86-64 for some brief technical info on the AMD64. A quick Google search turns up much more, of course.

JAL

According to that wiki page, it seems more like the processor itself can execute 16-bit code in long mode, only M$ couldn't make it work 😁

I'd have to agree with Taiken7...although I would really like a faster Dosbox for my 400 mhz, 256 megs of RAM, windows 98SE computer, I shouldn't be selfish.

See, dosbox was designed with modern, 2.5 gigahertz and above, 1 gigabyte or more of memory XP machines in mind, and some people including yours truly don't own a computer like that.

But even though a lot of my favorite games are painfully slow, I really can't ask the makers of DosBox to spend a lot of time rewriting the code for older Pc's...when way faster ones still don't have full support already!