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.
_______________________________________________
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
