Attached are some patches and files to add support for DMC. Tested against 4.2, but should work on 4.9 as well (with maybe a change or two to the makefile).

New Files:

• /include/allegro/platform/aldmc.h

• /makefile.dmc

Updated Files:

• /include/allegro/internal/alconfig.h

• /misc/fixver.sh

• /misc/fixdll.bat

• /misc/fixdll.sh

• /src/win/wsystem.c

• /tools/datedit.c

• /fix.bat

It basically works, but there are a few known problems that I haven't looked into yet. (For example, the demo.exe freezes while displaying the "Scanning" message.)

So for some notes...

Obviously it requires the base DMC compiler, and maybe an add-on package for rcc.exe or lib.exe, I don't remember. As with MinGW, it requires a mini dx7 package. I put one together; I'll post it later. And it also requires mingw32-make.

It's a C-only build. The makefile won't let you do anything else. I don't even know if assembler would be possible as-is. It doesn't really matter. The C and ASM DLL's are compatible for all practical purposes.

I had to add a few missing structs and miscellaneous stuff to the aldmc.h. It's possible that future versions of DMC will define some of it. But we can worry about that if it ever happens.

DMC requires extra header information in the allegro.def file. I added it to the fixdll scripts (untested). DMC does not support { and } in resource files. I renamed them to BEGIN and END in fixver.sh (untested). It's possible that those changes break MinGW32 or MSVC, but I doubt it.

DMC requires a DllMain() function, or else the DLL hangs. I added it unconditionally to /src/win/wsystem.c for all compilers.

The makefile is pretty much straightforward. The most annoying thing is that link.exe cannot accept forward slashes in the file names. As much as possible, I tried to limit the $(subst) by just using backslashes in the variable names. (This means if someone wants to add support for UNIXy environments, they'll have to hack around the slashes a lot.)

I had to do this:

OBJECT_LIST := $(subst dllver,,$(OBJECT_LIST))   
OBJECT_LIST := $(subst asmlock,,$(OBJECT_LIST))

asmlock.s is in the main Windows source object list. (Should it be?) I just manually cleared it from the list, since it's a C-only build. Also, DM's rcc.exe does not compile .rc files to .obj, so I had to remove dllver.obj out of the list. The resource file is linked in at the end instead.

I don't think plugins.h gets created ever. Doing a mingw32-make obj\dmc\plugins.h by hand fixes it.

Some of the compiler switches for the various modes (debug, profile, etc) could probably be improved upon. I didn't really read through what options dmc offered.

There's probably other things that I should mention, but that's all I can think of for now.

Edit: Here's dx70_dmc.zip.

I had to copy asmcapa.h over from obj/mingw32, and create the lib/dmc dir. I also copied over plugins.h, which didn't seem to make a difference for building the library.

I ran 'gmake ALLEGRO_USE_C=1 STATICLINK=1', and got this:

dmc   -L/SUBSYSTEM:WINDOWS -otests\win\dibgrab.exe obj\dmc\alleg_s\win\dibgrab.o
bj lib\dmc\alleg_s.lib kernel32.lib user32.lib gdi32.lib comdlg32.lib ole32.lib
dinput.lib ddraw.lib winmm.lib dsound.lib dxguid.lib
link obj\dmc\alleg_s\win\dibgrab,tests\win\dibgrab.exe,,lib\dmc\alleg_s+kernel32
+user32+gdi32+comdlg32+ole32+dinput+ddraw+winmm+dsound+dxguid+user32+kernel32/no
i/SUBSYSTEM:WINDOWS;
OPTLINK (R) for Win32  Release 7.50B1
Copyright (C) Digital Mars 1989 - 2001  All Rights Reserved

lib\dmc\alleg_s.lib(wgdi)
 Error 42: Symbol Undefined _gfx_gdi_unwrite_bank
lib\dmc\alleg_s.lib(wgdi)
 Error 42: Symbol Undefined _gfx_gdi_write_bank
lib\dmc\alleg_s.lib(wddwin)
 Error 42: Symbol Undefined _gfx_directx_write_bank_win
lib\dmc\alleg_s.lib(wddwin)
 Error 42: Symbol Undefined _gfx_directx_unwrite_bank_win
lib\dmc\alleg_s.lib(wddwin)
 Error 42: Symbol Undefined _gfx_directx_unlock_win
lib\dmc\alleg_s.lib(wddwin)
 Error 42: Symbol Undefined _gfx_directx_write_bank
lib\dmc\alleg_s.lib(wddwin)
 Error 42: Symbol Undefined _gfx_directx_unwrite_bank

--- errorlevel 7
gmake: *** [tests/win/dibgrab.exe] Error 7

So the librrary was built, but some symbols are missing. I haven't really looked into it yet. I'm using vanilla Allegro 4.2.1.

In case you haven't discovered it yet, the cl.exe tool that comes with translates msvc command lines into dmc ones. If you run it without any input files, it'll just print the msvc options.

It requires the latest SVN to work, since that contains the patches needed to build the C-only library.

As a side note, I'm pretty sure the I/O stuff doesn't work, as the grabber hangs when selecting a file and the demo hangs when reading the credits.

Ok, I got it working now. I tried the exhello example, but it looks weird. No text, only a small black square on a white background.

But thanks anyway, linking DAllegro statically with alleg_s.lib works now.

=====================================================
EDIT:
=====================================================
I built just the Allegro library with gcc, msvc6 and dmc, and timed it.

Command: 'gmake lib STATICLINK=1 ALLEGRO_USE_C=1'

GCC: 107 seconds
msvc6: 55 seconds
DMC: 42 seconds

btw, the free DMC version is unable to link dynamically with the C std library (msvcrt.dll), because SND.lib is not included in the free download. Kind of silly.

What limitations does this create? (And what's snn.lib?)

The only limitation I can think of is that the executables become larger.

snn.lib is the standard C library implementation that both dmc an dmd uses. It's for static linking. snd.lib is the import library that dmc needs for linking dynamically with the C library DLL (which isn't free either).

I wasn't sure this would work, but by using the implib tool available here, you can create an msvcrt.lib file that both dmc an dmd will accept. Which will enable you to link dynamically with msvcrt.dll (the msvc C std library implementation).

The implib command line:
implib /s msvcrt.lib %windir%\system32\msvcrt.dll

And put the resulting msvcrt.lib in your dm\lib dir. implib also accepts a .def file instead of a .dll.

I don't know whether doing this is likely to cause trouble, but my 'hello world' test app works fine. It's only that Walter Bright (dmc and dmd creator) seems to think that using msvcrt.dll for DMC or DMD won't work. So it could easily be a dead end. No big deal, though.

Okay, I'm not going to worry about mentioning the difference between the two in the Allegro docs. I did write up a simple document for building Allegro with DMC. (Some links may not be working yet.) It will serve as the basis for the ._tx documentation for inclusion with Allegro.

By the way, have you tried demo.exe built by DMC? For me it freezes when loading credits.

The demo works for me. But the gfx mode selection gui doesn't have any text readable text in it. And part of my desktop shows through the title screen.

EDIT:
It seems to just skip loading the credits. It doesn't show the file names as they are scanned, and it just displays the title screen without the credits.

Does al_findfirst work for you with the DMC build? For me it doesn't.

However, if I clear the os_type, it works. (os_type = OSTYPE_UNKNOWN;) This makes Allegro call _findfirst instead of _wfindfirst. Maybe this goes back to DMC not supporting _wfinddata_t?

I get the same results you do. Without setting os_type, al_findirst returns nonzero, but the file name is just an empty string. al_findnext then returns -1. errno is zero.

With os_type = OSTYPE_UNKNOWN it works just fine.

My test program:
http://pastebin.co.uk/17433

It's starting to look like a character encoding issue to me. That might explain the garbled text I get in the menus too.

personally I don't get it. Why would DMC have anything to do with a runtime error? Its using the system's libc. The only way its DMCs fault here is if its compiling wrong.

It works fine if you link dynamically with an allegro DLL built with msvc. It's dmc's own static lib build that doesn't work (which uses dmc's own C lib, not msvcrt.dll).

Ah. I had thought the last attempt was with the standard windows libc.

I don't have any problem with that. Could you try taking a screenshot?

That's basically what happens here. Although depending on the pattern, it behaves slightly differently. (Never properly.) To work around this for now, I can easily just change the find* routines to look for (OLD_WINDOWS || DMC).

For testing purposes, I changed title.c in demo to:

os_type = OSTYPE_WIN98;
for_each_file_ex(buf2, 0, ~(FA_ARCH | FA_RDONLY | FA_DIREC),
                    parse_source,
                    (void *)(unsigned long)(strlen(buf2) - 3));
os_type = OSTYPE_WINVISTA;

All the file stuff worked then.

Attached screenshot of demo gui. The screenshot is messed up, the only thing that didn't look right in reality was the menu text. The text looked exactly like in the screenshot.

EDIT: added a better screenshot, this time of ex3d.

Looks like its drawing all the letters one on top of the other. As if the letters are all 0 px wide.