In reply: @Rugxulo
I am replying under a new discussion thread as I didn't feel continuing this
detailed discussion under the Galactic Conquest thread was the right place.
> I read some (very old) newsgroup post earlier today where someone said they
> bought the RTL (except Graph) for TP6. So I guess it was available even
> then.
I would imagine that Borland licensed out their code in numerous ways to various people/organizations. On a similar reverse note UNPAK and UNZIP as provided with TP/BP/TC/BC were for example licensed by Borland from PKWARE.
> Only TP7 has the CRT startup bug, but TP55 still has a broken Delay. I
> think there are known fixes for that, but I haven't ever needed Delay yet.
Yes, I reminded myself of this after I posted I dusted TP5 off some more. Forgive me for not remembering as when the RT200 issue came around I had been using TP7 and TPW for ages and thus did not care (then) about TP5 fixes. Still if you think it is useful I will happily back port newdelay.pas to TP5 when I have a spare minute and am bored looking at other code like RJDUMP.
> and yeah, it's more convenient, but at least there are tools
> (INLIN219.ZIP)
Thank you for the reminder of that excellent program which I used a lot back with TP4/5/6. A good solution to a problem that I had forgotten existed ;)
> helping although even DEBUG probably is sufficient.
Indeed or any hex editor. What is sad is that I typed many of the op-codes I used directly into my example :) Hence only later did I notice (and fix) the fact that I had made a very small typing error (004Ch instead of 4C00h which as you know just happens to also be valid thus I didn't notice at first-only later when re-reading it!!
> However, I also heard that TP55 and older aren't pmode friendly, hence
I see no reason why TP5 can't be used for pmode, in otherwords not impossible.
> using the wrong interrupt vectors,
Firstly even in TP5 its usage of interrupt vectors can easily be fixed, e.g using "SwapVectors" at the most basic of levels or if you want to do it on a case by case basis via SaveInt00, SaveInt02, SaveInt1B, SaveInt23, SaveInt24, SaveInt34, SaveInt35, SaveInt36, SaveInt37, SaveInt38, SaveInt39, SaveInt3A, SaveInt3B, SaveInt3C, SaveInt3D, SaveInt3E, SaveInt3F, SaveInt75: pointer;
and then restoring them via SetIntVec/GetIntVec (DOS unit) or write your own.
Also note even without the variables possible to do this other ways as well.
> assuming hardcoded addresses, which aren't always true for pmode OSes.
Again can be worked around. Note: TP5 doesn't have SegB800, SegB000 SegA000 which can also be noted by their absence since in later versions of Turbo Pascal you can clearly see them stored at the end of the executable.
> (Note that I don't 100% understand this and have no examples of proof,
Ok, well look up the the above in TP5's help for starters [CTRL + F5 on a word of interest] and refer to Exec example which shows SwapVectors in use.
> but you probably know what I'm referring to.)
Yup. FYI, IVTUTIL which was written to be "open source" uses the individual method of restoring vectors as I wanted people to understand fairly clearly what it was doing/why. Really for better compatibility I should have used SwapVectors and it is likely when I update it to remove the semi-documented Interrupt patching feature I will change the code to instead use SwapVectors.
In short I program differently depending on what is required. I prefer well structured readable programs but when resources are limited that is different.
> > However importantly TP5 does of course also include external asm obj
> > logic.
> Yes, but I haven't tried that (and I hope it doesn't require explicit TASM
> or MASM object files or specific directives, e.g. "pascal"; I haven't tried
> yet but I hope JWasm or ArrowASM works).
To be honest checking it I was reminded that TP5 asm obj syntax is somewhat more annoying to use than later versions, however still better than inline.
> > Now I've shared some COM file generating
> > code you can hopefully re-use that to get the added benefit of asm size
> > with TP5!
> Not sure how space much this saves,
Here is the same example but one that compiles in TP5 but as an EXE instead:
Program TP5_BIG; {This is a BIG example to filesize compare against TP5_2COM}
{Freeware code example by Richard L. James http://www.wimborne.org/richard/ }
Var
XCounter, YCounter:Word; {These values are NOT saved but redefined below}
Begin
inline($B8/$00/$13/ {mov ax, 0013h} {Change to 320x200 graphics mode}
$CD/$10); {int 10h} {Call Int 10h}
For XCounter:=0 to 319 do {Generate a simple 320x200 picture}
For YCounter:=0 to 199 do
Mem[$A000:(YCounter*320)+XCounter]:=YCounter xor XCounter;
inline($31/$C0/ {xor ax,ax} {AX = 0}
$CD/$16); {int 16h} {Call BIOS to wait for a keypress}
inline($B8/$00/$03/ {mov ax, 0003h} {Change to 80x25 colour text mode}
$CD/$10); {int 10h}
inline($B8/$00/$4C/ {mov ax, 4C00h} {Terminate with an error code of 0}
$CD/$21); {int 21h} {End program}
End.
> Early TP (e.g. v1 or v302) only generated .COM files and also included the > whole runtime inside! (Still smaller than the C alternative.) So TP55
> output is actually a fair bit smaller (several kb).
Yup.
> Not sure how space much this saves, but I'll take a look later (if I don't
> forget!). 
If you compile the above with TP5 (museum version) you will get this EXE:
28/06/2010 14:03 1,392 TP5_BIG.EXE
If you use the TP5_2COM example to generate a COM file with the main TP5 code:
27/06/2010 12:23 99 TINYTP5.COM
So in answer to your question - 1,392 - 99 = 1,293 bytes saved :) Obviously anyone studying the COM file will immediately realize other optimizations can easily be made but this method can help makes that easier.
TP7 compiling the TP5_BIG.pas file (above) but appropriately renamed to help avoid confusion:
28/06/2010 14:26 1,712 TP7_BIG.EXE
The earlier TP5 code does however compile happily "as is" under TP7:
27/06/2010 23:29 97 TINYTP5.COM
So as you can see in the EXE example TP7 was larger but with the COM smaller, however be aware this was just a basic compare. However in both cases I used the "standard" RTL for both TP7 and TP5. That is both were compiled with "standard" TPL's, even untouched by any Run-time 200 fixes (on purpose I might add !).
Another example TP program to help compare some generated TP filesizes is the following:
Begin
{do nothing!}
End.
which in the case of TP1 compiles to:
27/06/2010 23:12 8,779 BEGINEND.COM
same program compiled with TP5:
28/06/2010 14:35 1,312 BEGINEND.EXE
and same program compiled with TP7:
28/06/2010 14:34 1,632 BEGINEND.EXE
Obviously the bytes that we discard when generating a COM file above have a very important use at times :) However I just wanted to show that there are some fairly easy techniques that can be used by the "EXE generating" versions of TP (in particular) including TP5 to help place TP generated code into other file formats (inc. SYS, boot sectors etc etc) for "certain" situations.
> > > Otherwise I'd just use GPC or FPC or VPC or whatever.
Yup and I'd be lying if I said that I only compile stuff with TP as I don't :)
> Found three different Pascal to C converters: p2c, ptoc, ptc. (Yes, they
> all are named horribly, heh.) 
Yes, played with all of them years ago. Related to the above I have also been various other methods for some time to convert existing Turbo Pascal code into other formats which enable a number of useful possibilities with TP.
However a *LARGE WATCHOUT*: What I should have commented about in my earlier discussion was WATCH OUT about the stack and various other watch outs but I'm guessing that most people reading this will be well aware of these issues anyway ;) If not if people just copy and re-use some of these examples and changing them without understanding them they will soon know about them !!!!
> Well, if you wanted to modify the stub, then okay. 
no comment :)
> I know the .EXE header wastes a bit of space,
It depends :) The relocation table entries (part of the header) are a pain in terms of size, e.g. with some TP generated files the header more than doubles the filesize - however the size of the header and size of various parts depends very much how the program has been written in the first place.
Indeed if you use lots of units, procedures, functions then your filesize will always go up, e.g. look up the entry and exit code per procedure. Note how many bytes they use then realize they bytes get added for each procedure.
An assembler procedure uses less entry/exit code than a standard procedure but far more problems can been encountered using it if you don't know what you are doing. Hence I have worked out ways to "combine" procedures and many other things which for shrinking files are very useful in addition to the well documented methods out there, e.g. replacement SYSTEM.PAS I suspect others have also worked similar but haven't shared.
Still for most projects having good readable code matters, so I'd rather not encourage too many bad habits/tricks myself but it has to be said that for projects were size really does matter (e.g.64k fixed ROM size) then it can be very useful to know them in order to generate ASM sized files with TP. |
Thread view
Board view