I've been testing hx dos with the different zdoom versions. zdoom v117c (win32) shows video, but doesn't work yet. However, there are a couple of reports that hx dos works with v217. There are hints here:
https://forum.zdoom.org/viewtopic.php?f=18&t=9198

The dosbox debugger helped find many of the win32 functions which are problematic in hx dos. I used the hx dos dpmild32 tool to run zdoom.exe [dpmild32 zdoom.exe].

For testing valiant.wad (2015) maps, the attached eternity.exe may replace the same filename from eternity-dos-v33302.zip. The following maps load with this update: 01, 05, 11, 19, 29.

The update is a workaround to startup errors:

1--- ETERNITY-ORIG//r_data.c	2017-04-22 22:17:17 -0400
2+++ ETERNITY//r_data.c	2017-05-05 01:25:51 -0400
3@@ -406,7 +406,7 @@ static void R_GenerateLookup(int texnum,
4 
5     texturecompositesize[texnum] = csize;
6     
7-    if (err)       // killough 10/98: non-verbose output
8+    if (0)       // killough 10/98: non-verbose output
9       {
10                 // sf: error_printf
11         error_printf("\nR_GenerateLookup: Column without a patch in texture %.8s",

Most of the maps in the Valiant megawad are dependent on the ZDBSP map format. It is listed as a MBF megawad, but requires a doom source port that supports this "zdoom extended node" format. There is a list of these ports from the doomwiki: ZDoom 2.5.0+, GZDoom 1.5.0+, PrBoom+ 2.5.0.7+, Eternity Engine 3.39.20+, Crispy Doom 2.3+ and Doom Retro 1.8+.

There is further discussion about it here:
https://github.com/fabiangreffrath/crispy-doom/issues/43

And the code is mainly in p_setup.c which I backported from crispy doom and chocolate doom. However, it showed that the megawad is not well supported under this version of Eternity for DOS. It seems that the memory requirements are too high for the ZDBSP maps, even though it is possible to load the presumably non-ZDBSP maps listed in the above post.

I haven't tested many other recent Boom- and MBF-compatible megawads to determine whether they load in Boom or MBF clients, or instead are actually ZDBSP maps (zdoom format).

The above memory limitation occurs with >110,000 nodes. Artificially limiting the # of nodes allows further reading of the uncompressed ZDBSP format. However, continued reading of this extended format leads to an error in P_RemoveSlimeTrails(). Removing that function remedies the errors and loads the level, but there is no further progression beyond 2 iterations in a loop of P_LoadThings().

Also, tested with z_zone.* memory functions, but without an effect. One test is to verify the ZDBSP code by incorporating it into Zdoom-CL. If that works, then it may be possible to replace the z_zone memory allocations with a general allocation function which is robust with high memory use.

Segmentation violation confirmed by building v3.39.20 a DOS binary. Shows very similar error to v3.33.02 with the uncompressed ZDBSP code. However, it can start vanilla doom until a level is loaded. Attached the patch for v3.39.20 so others could repeat the test.

Also, attached patch to build the Eternity v3.33.02 DOS version with support for the uncompressed ZDBSP map format. This shows an error like in v3.39.20 where loading the zdbsp maps. Attempted several tries to debug and it is possible to modify code to load a vanilla doom map, but there seems to be many places in the zdbsp code which conflict with the DOS memory system. An above post has further details.

From testing in the older Windows versions of Eternity, the map format is not necessarily the only incompatibility in zdbsp style maps, so I think Zdoom-LE is an alternative in Windows 95. It should be possible to port features back to Zdoom-CL, but there are other features in recent maps which suggest Zdoom-LE as a better choice.

Current maps, including those listed as Boom compatible, should be tested against clients other than zdoom and its derivatives. The alternative is to have other doom ports continually porting zdoom code back into their clients. This limits the ports in pursuing their goals and results in a single thread of engine development.

Attached Eternity DOS build (v3.33.02-2). Includes patches. These binaries are unsupported, user takes responsibility for their use.

Attached experimental version of Eternity DOS build (v3.39.20). Includes patches. These binaries are unsupported, user takes responsibility for their use.

Note that this version is currently set at VGA only and the ZDBSP maps require >192Mb of RAM. The console input is very slow after starting a level and not all levels will load. Testing with Valiant megawad.

Attached Eternity DOS build (v3.39.20). Includes patches with detailed information. The above issues were resolved. These binaries are unsupported, user takes responsibility for their use.

Resolution is changed by v_mode command and ZDBSP maps may require >256Mb of RAM.

Attached Eternity DOS build (v3.39.20-2). Includes patches and a readme file. Fixed issues with menu options. These binaries are unsupported, user takes responsibility for their use.

Edit: tested several zdoom 1.23 beta and 2.0 wad files. They load in this version of Eternity, but they depend on MAPINFO and a few missing thing types. However, it is possible to use "noclip" to bypass the areas dependent on the thing types. An example is the Invisible Bridge (thing type 9990).

Below is a Perl script to help in converting the MAPINFO to EMAPINFO so that Eternity may read the level information:

1# Converting MAPINFO from old zdoom format to eternity v33920
2#  export MAPINFO from megawad to local drive via a lump editor (SlumpEd)
3#  use Perl script to help convert MAPINFO to EMAPINFO format
4#  create a new lump named EMAPINFO in megawad
5#  copy script output to EMAPINFO and verify it looks correct
6#  save the changes
7
8while(<>){
9	@array_sky=();
10	@array_music=();
11	@array_levelname=();
12
13	chomp;
14	if($_ =~ /^map/){
15		   $valid_block=1;
16		   $x++;
17		   print "[MAP0",$x,"]\n";
18
19		   @array_levelname = split(/"/,$_);
20		   $array_levelname[1] =~ s/"$//;
21		   print "levelname=",$array_levelname[1],"\n";
22	}elsif($_ =~ /^sky/){
23		@array_sky = split(/ /,$_);
24		print "skyname=",$array_sky[0],"\n";
25		# print "sky2name=",$array_sky[1],"\n";
26	}
27	elsif($_ =~ /^music/){
28		@array_music = split(/ /,$_);
29		$array_music[1] =~ s/^D_//;
30		print "music=",$array_music[1],"\n\n";
31	}
32}

Attached Eternity DOS build (v3.39.20-5). Includes patches and a readme file. Fixed additional issues with menu options and backported code bits from Allegro v442. User takes responsibility for use of binaries.

... sorry wrong thread.

I've tried your last version of eternity and now it won't run in dosbox, crashes with a no DPMI error.
About DOOMGL i think the source code got lost and was recovered much later.

"About DOOMGL i think the source code got lost and was recovered much later."

I have opened another thread. I have tested a lot, but these old DoomGL/Hexen/Heretic are simply fast and look amazing on old hardware and therefore my favorites. I'll have to checkout, if there are sources available.

Attached Eternity DOS build (v3.39.20-7). Includes patches and a readme file. Fixed additional issues with menu options, added a video mode console option, and reduced the size of the Allegro library dependency by excluding support for non-8-bit color depths. User takes responsibility for use of binaries.

Same as previous version in Dosbox (Daum and ECE): 'Load Error : no DPMI memory'. Old versions worked.