koverhbarc wrote:

Any ordinary DJGPP program runs under XP (including all those I've written), and I believe DPMI should be managed automatically.

I'm a bit fuzzy on the details, but I understand such programs will automatically rely on the DPMI services provided by the NTVDM rather than CWSDPMI – and that can cause problems.

Note that for old hardware or old operating systems you should ask in Marvin. Marvin, the Paranoid Android

collector wrote:

Note that for old hardware or old operating systems you should ask in Marvin. Marvin, the Paranoid Android

He's okay in this forum so long as he sticks to wanting to run DOS games natively in XP. If he veers to Win98, then we can move it. 😁

Stiletto wrote:

He's okay in this forum so long as he sticks to wanting to run DOS games natively in XP. If he veers to Win98, then we can move it. 😁

Which is why I told him to be aware of it since he mentioned trying it with Win98.

koverhbarc wrote:

Is Win98 an improvement over XP at all (without booting into 'MS-DOS mode') - I don't think so, but I do have copies of 98 that I could install if I was willing to screw around with my hard disk.

I think the question is more important than debating what forum it should be in. If someone wants to move it I wouldn't object.

In short: what is behind this 'DOS near pointers' error and is it fixable within XP? I searched the exact text of the error given by Doom source ports, 'Failed trying to allocate DOS near pointers.', and found nothing on Google.

As fantastically popular as Doom is, there's got to be someone out there who's done some work on the problem.

If it does come down to the NTVDM's DPMI services, then the solution would require somehow patching those services – but I'm not sure anything like that has been done before.

I remember I played DOOM (or was it DOOM II ?) on Win XP. With sound. I think I had to manually enable NTVDMs's SB 2.0 emulation.

Oh, and there also was VCPI.. A few games used it, I think.

I believe I have just answered this. Note that the text of the error message about 'DOS near pointers' is specific to Doom source ports and other programs having the same issue may just hang (as noted) or drop to DOS with a segfault, etc.

I figured it out by just looking in the source code for MBF and it was very easy to find: what is being called 'DOS near pointers' are this: http://www.delorie.com/djgpp/v2faq/faq18_6.html , which will not work under XP; fundamentally, because the OS must reserve some virtual memory for itself that the program can't access. There is no workaround except changing the program's source code, as was indeed done for MBF 2.04 ; without source, it's not possible if the 'near pointers' are being used for video (if they weren't a binary patch might be possible to shrink the segment limits).

Though that function is specifically DJGPP, other DOS games undoubtedly used it and therefore won't run. Protected-mode programs that aren't DPMI almost certainly can't be supported either, you can't set up your own protected mode under an environment that's already done it!

In terms of Doom, the 'work' that was done on the problem was developing source ports for Windows rather than DOS, which was occurring at the same time XP was introduced. It was then unnecessary to fix the problem in DOS versions; and the original 'vanilla Doom' fortunately doesn't have the near pointer issue and can run as noted.

koverhbarc wrote:

you can't set up your own protected mode under an environment that's already done it!.

Not sure if that's true. Windows 3.1's 16bit kernel (VCPI compliant) can execute under Win95.

koverhbarc wrote:

Any ordinary DJGPP program runs under XP (including all those I've written)

In fact, XP is the recommended system for DJGPP development, at least in the current DJGPP 2.05 version.

you can't set up your own protected mode under an environment that's already done it!.

Not sure if that's true. Windows 3.1's 16bit kernel (VCPI compliant) can execute under Win95.

You can't enter protected mode the normal way while being in a vm86 environment because you need RING 0 to do that.
This is where VCPI and DPMI interfaces come in. They allow you to jump into p-mode segment without having to set up your own protected mode environment.

Whe you run DJGPP program in MS-DOS, it runs its own DOS-extender (CWSDPMI). But under Windows CWSDPMI cannot run. Windows provides its own DPMI interface as part of NTVDM. Any CWSDPMI-specific features are not available in such scenario, unless they can be faked or emulated somehow by DJGPP's runtime.

Azarien wrote:

you can't set up your own protected mode under an environment that's already done it!.

Not sure if that's true. Windows 3.1's 16bit kernel (VCPI compliant) can execute under Win95.

You can't enter protected mode the normal way while being in a vm86 environment because you need RING 0 to do that.
This is where VCPI and DPMI interfaces come in. They allow you to jump into p-mode segment without having to set up your own protected mode environment.

Thank you, I'm aware of this. I think it is impressive, though, that a non-DPMI (VCPI) protected mode program can run on Win95,
even though Win95 does not support VCPI. I wonder how this is accomplished. As far as I know, only Win-OS/2 was a DPMI capable client.

Edit: Interesting - I've found contradictory information about Windows 3.1 and DPMI.
The original idea was that Windows 3.1 is a DPMI host, but not a DPMI client (but a VCPI client at some point)..
https://www.betaarchive.com/forum/viewtopic.php?t=26144
http://collaboration.cmc.ec.gc.ca/science/rpn … 9406m/9406m.htm

koverhbarc wrote:

I've been curious about this for while now. I thought I knew how Windows provided memory to DOS programs, but some games don't work under XP and I'm not sure why. Any ordinary DJGPP program runs under XP (including all those I've written), and I believe DPMI should be managed automatically.

I always ALWAYS had to keep a cwsdpmi* or something like that in the same folder as several DOS exe files just to be able to run those properly, because else it would straight up refuse, like DBOY emulator.

Icelordetherea wrote:

I always ALWAYS had to keep a cwsdpmi* or something like that in the same folder as several DOS exe files just to be able to run those properly, because else it would straight up refuse, like DBOY emulator.

You mean under Windows XP? Because cwsdpmi.exe is not required on Windows.

One would think not but I suppose it's possible that some programs depend on cwsdpmi specifically and not just any DPMI host. I'm not sure if it actually gets loaded under Windows because I've never needed to deal with anything like that.

I think the DJGPP stub loader checks if DPMI is available, and if not, only then loads cwsdpmi.exe

koverhbarc wrote:

And indeed - ignoring sound for now - DOS real-mode games work unless they attempt to do something with the hardware that XP can't emulate. But protected-mode games (I guess that's synonymous with '32-bit' - did any DOS games ever use 16-bit protected mode? Win 3.x games did, of course.) are different. I will use Doom as an example because it's so widely distributed and it illustrates more clearly than other games which can just hang.

I can mention one: Maniac mansion 2: Day of the Tentacle. It runs in 80286 protected mode(16-bit protected mode). Probably more games from the AT-era as well.

No, according to the info I just looked up DOTT was a real mode game (also 1993 can't really be called the 'AT era'). If a game's minimum CPU is a 286 (and I'm not sure for that game), that doesn't imply protected mode use (as with Wolfenstein 3D - also real mode).

I would be pretty confident that games didn't use 16-bit protected mode because it normally can provide little performance advantage over real mode + XMS and required significantly different programming. By the time games were getting big enough to give sufficient reason for it, they wanted to go 32-bit instead for a much bigger leap and could target 386+ machines only.

I'm pretty sure it's a protected mode game:
http://www.cdaccess.com/html/shared/dott.htm

It does say the minimum is a 80286. Also, during UniPCemu's debugging, I see it using protected mode(CR0 bit 0=1). Since it's minimum is a 80286, it must be made for 16-bit protected mode(80286 doesn't support 32-bit protected mode).

superfury wrote:

I'm pretty sure it's a protected mode game:
http://www.cdaccess.com/html/shared/dott.htm

It does say the minimum is a 80286. Also, during UniPCemu's debugging, I see it using protected mode(CR0 bit 0=1). Since it's minimum is a 80286, it must be made for 16-bit protected mode(80286 doesn't support 32-bit protected mode).

I find it hard to believe it is a protected mode game, but I'll believe it when given enough proof.

Are you absolutely sure it was the game that sets it, or was it memory manager (himem handling extended memory or emm386 that has set up vm86) or BIOS (int15 extended mem functions)?