VOGONS

Common searches


First post, by paolo-sz

User metadata
Rank Newbie
Rank
Newbie

I just discovered DOSBox is not completely abandoned so I checked-out the svn version and I tried to build it with my mingw installation just to discover not all the code (zmbv codec) is compilable. Here is a patch which enables a full mingw build (32 and 64 bits), including zmbv codec.

By the way, I also took the patch from this interesting topic (by NY00123) An adaptation to SDL 2.0 (Alpha-level Android build attached) and, with some changes (removed android, re-enabled cdrom), I got a nice DOSBox based on SDL 2.0 up and running. If anyone is interested just drop me a message (I do not ensure a fast response, sorry) or follow the above topic.

Have a nice DOSBox session!

Attachments

  • Filename
    zmbv_mingw_r3873_20141206.patch
    File size
    656.95 KiB
    Downloads
    186 downloads
    File comment
    zmbc codec mingw compilable patch
    (based on subversion rev. 3873)
    File license
    Fair use/fair dealing exception

Reply 2 of 5, by paolo-sz

User metadata
Rank Newbie
Rank
Newbie

Well, there is not a specific error, the zmbv codec is not built at all if you use mingw and autotools.

Indeed most of the patch is due to the fact that the zmbv codec is a dll and then I need libtool in order to let autotools to generate a shared library.
The rest of the patch is mostly changes to zmbv codec sources for 64 bits build where I cannot use anymore the first 32 bits parameter (dwDriverID) of the DriverProc function to pass the address of the driver which is obviously 64 bits in a 64 bits build...

Reply 3 of 5, by truth_deleted

User metadata

That codec doesn't have to be built by the dosbox package. Neither is SDL built by dosbox, but instead it is detected in a configure script. Dosbox currently has a simple compile process which will be made unwieldy by that unnecessary code in the above diff file.

The patch for the 64-bit build may be useful. I presume you tested the 32-bit build and your patch is unnecessary for that case? If it's just the 64-bit build, then that may be interesting to verify and design a patch specifically for that purpose.

Reply 4 of 5, by paolo-sz

User metadata
Rank Newbie
Rank
Newbie
truth5678 wrote:

That codec doesn't have to be built by the dosbox package.

I completely disagree with you. zmbv codec is distributed within the DOSBox nsis installer so I feel it IS part of dosbox build and should be built by dosbox package.

truth5678 wrote:

Neither is SDL built by dosbox, but instead it is detected in a configure script.

Please, read carefully my first post. I NEVER claim the attached patch has something to do with SDL which is still detected in the configure script like you said.

truth5678 wrote:

Dosbox currently has a simple compile process which will be made unwieldy by that unnecessary code in the above diff file.

My patch does not have impact in most of the dosbox package compilation process neither in the command that need to be issued by the developer (completely unchanged), nor in the real commands used to compile every single source file. The only real difference is that libtool command is issued (by the make process and completely transparently to the user) in order to compile zmbv codec and final dosbox executable.

Without my patch if you want to create the nsis installer package you need to:
1. compile dosbox with mingw
2. compile zmbv codec by visual studio
3. copy some files to the nsis scripts folder
4. generate the nsis installer

With my patch you completely drop point 2 so I feel my patch is simplifying the process, not the opposite.

truth5678 wrote:

The patch for the 64-bit build may be useful. I presume you tested the 32-bit build and your patch is unnecessary for that case?

This is not completely true. As I said, zmbv codec was not built at all by mingw and autotools process. Once I tried to compile it with mingw I found several problems also in the 32 bit compilation (mainly coding style not strictly related to 32 or 64 bits compilation process but to gcc itself) so part of the patch is made to fix those problems.

Here is a detailed description of the whole contents of the patch:
- everything included in build-scripts folder and ltmain.sh: libtool support files added from scratch
- autogen.sh: changes for added libtool script file support
- configure.ac: 5 differences which are, in the order: libtool initialization, better library order, some more libraries needed by my mingw, better library order, some more libraries needed by my mingw.
- scripts/dosbox-installer.nsi: mainly support for the 64 bit build and a patch (Sleep 100) for a folder not removed by the uninstaller.
- src/dos/cdrom_aspi_win32.cpp and src/dos/cdrom_ioctl_win32.cpp: my mingw has some include in a different folder
- src/libs/zmbv/64/zmbv.inf: new .inf file for 64 bits build
- src/libs/zmbv/Makefile.am: the new Makefile.am which now build the zmbv codec with autotools (libtool)
- src/libs/zmbv/drvproc.cpp: mainly 64 bits patch (include also type realignment to MSDN documentation)
- src/libs/zmbv/drvproc.h: file needed in order to add the "#ifdef __cplusplus" that fix the exports naming convention in a MS installable driver understandable foarmat
- src/libs/zmbv/zmbv_vfw.cpp: type realignment to MSDN documentation and current patch realignment
- src/libs/zmbv/zmbv_vfw.h: type realignment to MSDN documentation
- src/libs/zmbv/zmbv_vfw.rc and src/libs/zmbv/zmbv_vfw_rc.rc: renamed file because of naming conflict (.o) during compilation

The MSDN documentation I'm referring to could be found in http://msdn.microsoft.com/en-us/library/dd756 … v=vs.85%29.aspx