The first patch (noasm) should be applied before the 2nd (vcproj). I've tried applying both and then building a .lib file with them in MSVC, no errors.

The first patch duplicates the functionality of asmlock.s in the preexisting source files wddlock.c and wgdi.c (some functions from asmlock.s go in one, some in the other). It also modifies adds a few extra things to wddraw.h which were used in multiple files but not listed in header files. It also changes a comment pertaining to asmlock.s in the wddwin.c file.

The point is to make the windows code work without any .s files.

The second patch changes a single line of poly3d.c in order to make it compile if ALLEGRO_NO_ASM is defined and no asmcapa.h has been generated. That change makes Allegro (or at least, allegro/win32) not depend upon asmcapa.h when ALLEGRO_NO_ASM is defined. It also adds a new directory VisualC_net, and VisualC 7.1 project files in that directory capable of building static no-asm versions of Allegro. Unfortunately, the project produces a bunch of warnings about __NULL_IMPORT_DESCRIPTOR, but a few quick google searches found no solution to the warnings. The resulting .lib appears to produce working executables. The patch also creates new directories in obj/msvc to hold object files for the MSVC no-asm static builds of Allegro.

The point is to make the windows code work on MSVC without the normal Allegro build process (which requires DJGPP or MinGW). Unfortunately, there are flaws:

It builds a static lib because a dll would not be binary compatible with the existing dlls, due to the calling conventions used in the asm window locking code. The obvious solution would be to add an asm version that MSVC can understand (perhaps inline asm) to match the calling conventions, but that would be MSVC-specific, and only useful in a dead-end path, since 4.3.0 is planning to ditch the non-standard calling conventions on the window locking code.

It produces spurious warnings. I do not know of a solution to this for static libs, but it is supposed to go away when a dll is built instead.

The project does not build the examples, tools, or demo. I don't know an easy way to generate a bunch of small projects like that.