- BORLAND/: Borland C++ 4.52 (chosen over 4.5 by byte-match: CODE/RP/CW32.LIB
is identical to 4.52's install lib). BCC32/TLINK32/TLIB/MAKE run natively on
Win11; CODE/BT/OPT.MAK is the shipped BTL4OPT.EXE's exact flag recipe
(extender = Borland PowerPack DPMI32, not Phar Lap TNT).
- restoration/source410/: the literal 1995-form reconstruction of the missing
BT game source (never mixed into CODE/). Round 1-3 state:
* 6 of 10 surviving original TUs COMPILE CLEAN under the period toolchain
(BTMSSN, BTCNSL, BTSCNRL, BTTEAM, BTL4MODE, BTL4ARND) - first builds
since 1996.
* BT_L4/BTL4APP.CPP pilot reconstruction: 12/12 functions, Fail() lands on
its binary-recorded line 400 exactly.
* BT/BTCNSL.HPP: console wire IDs recovered from the binary's ctors
(Killed=9, Damaged=10, ScoreUpdate=13, DeathWithoutHonor=15 [T1];
TeamScore=12 flagged [T4]).
* MUNGA/: 8 engine-header backfills back-dated from the BT412 WinTesla tree
(VDATA numbering decomp-verified; AUDREND's OpenAL-era virtual removed -
the period compiler is the drift detector).
* Tooling: backdate.py (WinTesla->1995 header transform), compile410.sh
(per-TU verification sweep under authentic OPT.MAK flags).
* README: corrected roadmap - MECH.HPP is the capstone grown with the mech
TU reconstructions; BTREG.CPP green = the header-family milestone.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
58 lines
2.3 KiB
Plaintext
58 lines
2.3 KiB
Plaintext
Instructions for the ide example STYLESHT.IDE.
|
|
//
|
|
// Instructions for StyleSht.ide
|
|
// Copyright Borland International, 1993
|
|
//
|
|
|
|
Note:
|
|
[This example builds on another example in the 'SrcPool' directory that
|
|
walks throught how build a multi-target project using abstract SourcePools
|
|
and reference-copies. A general understanding of that example is assumed
|
|
here. Although SourcePools and reference copying are used in this example,
|
|
they are by no means necessary for using StyleSheets.]
|
|
|
|
|
|
This example shows how applying StyleSheets can dramatically ease the
|
|
process of creating multiple targets based on the same source code with
|
|
completely different results: one target is designed for debugging and
|
|
pre-production, while the other target, using the exact same pool of
|
|
source code creates a 'delivery' edition with no debugging symbols and
|
|
fully optimized for a different platform.
|
|
|
|
Anywhere along the way you can inspect the impact of setting options
|
|
and assigning StyleSheets by using the Options Inspector. You can reach
|
|
the Inspector by:
|
|
|
|
1) Bring up the SpeedMenu for node in the Project View by hitting
|
|
the right-button while the cursor is over that node.
|
|
2) Select 'View options hierarchy'
|
|
|
|
To see the full effect of this example select:
|
|
|
|
Options|Environment|Project View|Style Sheet
|
|
|
|
This will allow you see the Style Sheets assigned throughout the tree
|
|
while in the Project View.
|
|
|
|
As you can now see, the styles16 [.exe] will be created with full debugging
|
|
on, whereas the styles32 [.exe] will be created with debugging off and
|
|
optimized for speed. Please note that even though the "My Styles Source"
|
|
SourcePool is reference copied, applying these StyleSheets (or any
|
|
local overrides) at the reference nodes, has no effect on the other copies
|
|
and allows maximum flexibility for creating the right targets.
|
|
|
|
This is accomplished with the following steps:
|
|
1) Bring up the SpeedMenu for the SourcePool under stylesht16 by hitting
|
|
the right-button while the cursor is over that node.
|
|
2) Select 'Edit node attributes'
|
|
3) Select from the drop-list called StyleSheets one of pre-existing
|
|
StyleSheets to apply to the node.
|
|
4) Optionally you can create your own StyleSheet (either based on a
|
|
pre-existing one, or from scratch) by pushing the 'Styles...'
|
|
button in this dialog or from Option|Style Sheets from the main
|
|
menu.
|
|
|
|
|
|
|
|
|