[fpc-pascal] updating an old DOS tool using PChar strings

[waldo kitty]

On 2/19/2014 6:10 PM, Tomas Hajny wrote:
> On Wed, February 19, 2014 23:58, leledumbo wrote:
>> Well, if you're not using FPC, then asking for non-FPC code here isn't the
>> right way. It's useless to point yout o FPC units that BP7 doesn't have.
>> As
>> you've experienced, ReplaceStr (from StrUtils), StringReplace (from
>> SysUtils) are FPC and Delphi routines, and BP7 doesn't have those units
>> AFAIK. They don't work with PChar anyway.
>
> I'd add:
>
> - It is not clear to me why FPC should be more problematic than BP7 (I
> assume that you do not talk about a 286 PC;

correct for the most part...

> even if you do, trunk with the plain 16-bit msdos support might still do it
> for you).

i've pulled DOS262 with the GO memory extender but have not yet installed it on 
the system due to other questions not yet posed...

i'm not sure what "trunk with 16 bit support" you speak of... i think it may be 
the recent work being done on 8086 support... is this right? if so, then trunk 
/may/ be where i want to go /but/ my OS/2 box doesn't have the ability to pull 
trunk and compile the DOS version... at least, not as far as i know... so far, 
i'm been relegated to pulling and installing the release snapshots on my OS/2 
box... my winwhatever boxen, on the other hand, do pull and use trunk... at some 
point i hope to figure out how to perform cross compiling on so that i can work 
on a project on any platform and compile it for any other environment... this is 
part of the above mentioned questions not yet posed ;)

i don't really think that this particular tool (or numerous others i have at 
hand) need a DOS extender since they all currently operate in an old school 
plain jane DOS environment without need of XMS or EMS... 64k heap is more than 
enough for the PChar strings this tool has to work with...

> What is the exact execution environment where you intend to use the compiled
> program (operating system, CPU type)?

basically, it will be the (4)DOS environment on my eCS machine but the program 
may also be released to others for use on their DOS environments... whether 
that's DOS4 up to DOS6 native or in a VM device of some sort, i don't know... if 
it is using a command interpreter replacement like 4DOS, i don't know... my 
personal environment does use 4DOS... especially for my BBS controls ;)

i have been asked about releasing this tool so that others can use it which is 
why i want/need to fix the few problems it has that i know about and why i don't 
know what DOS environment it will be running under... it is not so far out of 
the realm of possibility that a vintage 286 might be employed by a BBS sysop 
wanting a truly retro environment for their setup...

> - It is not completely clear what is the goal/task (e.g. whether it is
> necessary to modify the PChar string in place, or whether it is OK to
> convert PChar to a Pascal string first,

the data pulled from the database file is not of a format that can be converted 
to pascal strings... it can easily be longer than 255 characters and may also 
have embedded EoL sequences... i did actually try (yesterday) to do this 
conversion to pascal strings and perform the replacements but it was using a mix 
of BP7's PChar functions and those of the CStr unit previously mentioned... 
needless to say, they are obviously not directly compatible and all attempts 
were met with 204 runtime errors which, even after stopping this work and the 
execution of that flavor of the tool, resulted in the system totally locking up 
and requiring the use of the big red switch followed by a chkdsk over all of the 
6 drives/partitions used :/

incompatibility between the CStr unit routines and the native BP7 routines is 
the best explanation i have at this time since the CStr unit sets up its own 
buffer and similar operating capabilities... considering the age of the unit, i 
think it could also be used with TP/BP6 but i never tried since they didn't do 
PChar stuff in TP^/BP6 TTBOMM...

overall, the goal is to simply pull the null terminated data from the data files 
and writeln it to a plain ascii text file... this part currently works but there 
is the additional goal of converting the tool so as to be able to change certain 
substrings within the PChar strings and writeln the final result as is currently 
being done...

> perform all the necessary operations on it and then pass a pointer to the
> string data as a PChar for some other processing expecting a PChar
> parameter).

currently, the only thing done with the PChar strings is to pull them and 
writeln them to the output file... previous attempts at reformatting them 
failed... since they just worked as they were, i took the easy way out and 
didn't worry about dealing what i'm looking at now after 10 years or so...

as far as passing pointers and processing in place or passing a copy to be 
returned goes, that's really of no concern to me as long as it is possible that 
the data can have substrings altered to their html entities so as to be able to 
pass the W3C html validation for the generated text files...

thanks for your response, tomas!

-- 
NOTE: No off-list assistance is given without prior approval.
       Please keep mailing list traffic on the list unless
       private contact is specifically requested and granted.