Rooba
/
ReC98
mirror of https://github.com/nmlgc/ReC98.git
1
1
Fork 0
Code Issues Packages Projects Releases Wiki Activity
ReC98/build32b.bat

45 lines
1.4 KiB
Batchfile
Raw Normal View History

Add build batch files and some documentation about the build process So yeah, that'll be our build environment - just plain batch files calling the Borland command-line assembler, linker, and eventually C compiler. These are the exact tools that ZUN used as well. There certainly are other assemblers, compilers and linkers that could compile this code into 16-bit DOS executables; Open Watcom is the only free one I know, and the master.lib manual also mentions C compilers by Microsoft and Symantec. However, I favor having one clear build path for a single toolchain that will, with the correct command-line switches for each game, create builds that are bit-perfect to ZUN's original ones over the possibility of cross-platform builds and the maintenance nightmare they add. So, Borland-only it is. (Also, no Makefile, due to our messy build setup. I think I still prefer this solution though, as we can have these really nice error messages that double as build instructions without any dependencies on installed software.)
2015-02-15 22:32:32 +00:00
@echo off
echo Running the first, 32-bit part of the ReC98 build process.
Let Turbo C++ link in the Borland C/C++ runtime for the main EXE files This took long enough, so we're not covering the COM files right now. Like, I can't even tell how you're supposed to work around the forced word alignment for the _TEXT segment. Guess we'll just have to decompile all of these in one go, just like we did with ZUNSOFT.COM. Also, it really seems as if we're merely trading one ugly workaround for another in our quest for identical binaries.
2015-02-19 06:46:36 +00:00
set ReC98_ASM=tasm32 /m /mx /kh32768 /t /ilibs\master.lib\
Add build batch files and some documentation about the build process So yeah, that'll be our build environment - just plain batch files calling the Borland command-line assembler, linker, and eventually C compiler. These are the exact tools that ZUN used as well. There certainly are other assemblers, compilers and linkers that could compile this code into 16-bit DOS executables; Open Watcom is the only free one I know, and the master.lib manual also mentions C compilers by Microsoft and Symantec. However, I favor having one clear build path for a single toolchain that will, with the correct command-line switches for each game, create builds that are bit-perfect to ZUN's original ones over the possibility of cross-platform builds and the maintenance nightmare they add. So, Borland-only it is. (Also, no Makefile, due to our messy build setup. I think I still prefer this solution though, as we can have these really nice error messages that double as build instructions without any dependencies on installed software.)
2015-02-15 22:32:32 +00:00
Rename all code segments to names that Turbo C++ would generate Well, duh, of course, we *can* do this in order to allow decompilation to be started at the end (not the beginning) of any segment. In fact, if we hadn't done this, we would have had to start by moving _TEXT out to libraries....
2015-02-21 11:47:24 +00:00
del /S *.obj
Add build batch files and some documentation about the build process So yeah, that'll be our build environment - just plain batch files calling the Borland command-line assembler, linker, and eventually C compiler. These are the exact tools that ZUN used as well. There certainly are other assemblers, compilers and linkers that could compile this code into 16-bit DOS executables; Open Watcom is the only free one I know, and the master.lib manual also mentions C compilers by Microsoft and Symantec. However, I favor having one clear build path for a single toolchain that will, with the correct command-line switches for each game, create builds that are bit-perfect to ZUN's original ones over the possibility of cross-platform builds and the maintenance nightmare they add. So, Borland-only it is. (Also, no Makefile, due to our messy build setup. I think I still prefer this solution though, as we can have these really nice error messages that double as build instructions without any dependencies on installed software.)
2015-02-15 22:32:32 +00:00
for /L %%i in (1,1,5) do mkdir bin\th0%%i 2>NUL
%ReC98_ASM% 1>NUL 2>NUL
if errorlevel 9009 goto no_tasm32
Let Turbo C++ link in the Borland C/C++ runtime for the main EXE files This took long enough, so we're not covering the COM files right now. Like, I can't even tell how you're supposed to work around the forced word alignment for the _TEXT segment. Guess we'll just have to decompile all of these in one go, just like we did with ZUNSOFT.COM. Also, it really seems as if we're merely trading one ugly workaround for another in our quest for identical binaries.
2015-02-19 06:46:36 +00:00
%ReC98_ASM% th01_op.asm bin\th01\op.obj
%ReC98_ASM% th01_reiiden.asm bin\th01\reiiden.obj
%ReC98_ASM% th01_fuuin.asm bin\th01\fuuin.obj
Add build batch files and some documentation about the build process So yeah, that'll be our build environment - just plain batch files calling the Borland command-line assembler, linker, and eventually C compiler. These are the exact tools that ZUN used as well. There certainly are other assemblers, compilers and linkers that could compile this code into 16-bit DOS executables; Open Watcom is the only free one I know, and the master.lib manual also mentions C compilers by Microsoft and Symantec. However, I favor having one clear build path for a single toolchain that will, with the correct command-line switches for each game, create builds that are bit-perfect to ZUN's original ones over the possibility of cross-platform builds and the maintenance nightmare they add. So, Borland-only it is. (Also, no Makefile, due to our messy build setup. I think I still prefer this solution though, as we can have these really nice error messages that double as build instructions without any dependencies on installed software.)
2015-02-15 22:32:32 +00:00
%ReC98_ASM% th02_zuninit.asm bin\th02\zuninit.obj
%ReC98_ASM% th02_op.asm bin\th02\op.obj
%ReC98_ASM% th02_main.asm bin\th02\main.obj
%ReC98_ASM% th02_maine.asm bin\th02\maine.obj
%ReC98_ASM% th03_zunsp.asm bin\th03\zunsp.obj
%ReC98_ASM% th03_res_yume.asm bin\th03\res_yume.obj
%ReC98_ASM% th03_op.asm bin\th03\op.obj
%ReC98_ASM% th03_main.asm bin\th03\main.obj
%ReC98_ASM% th03_mainl.asm bin\th03\mainl.obj
%ReC98_ASM% th04_res_huma.asm bin\th04\res_huma.obj
%ReC98_ASM% th04_op.asm bin\th04\op.obj
%ReC98_ASM% th04_main.asm bin\th04\main.obj
%ReC98_ASM% th04_maine.asm bin\th04\maine.obj
%ReC98_ASM% th05_res_kso.asm bin\th05\res_kso.obj
%ReC98_ASM% th05_op.asm bin\th05\op.obj
%ReC98_ASM% th05_main.asm bin\th05\main.obj
%ReC98_ASM% th05_maine.asm bin\th05\maine.obj
goto eof
:no_tasm32
echo Could not find TASM32.
echo Please make sure that the BIN directory of Turbo Assembler 5.0 is in your PATH.
goto eof
:eof
Finally use standard segment names everywhere And I guess we just have to ignore and disable that segment alignment warning for TH01. It's not like this changes anything in the binary.
2015-02-18 11:07:37 +00:00
echo -------------------------------------------------------------------------------