i have an old DOS tool written in BP7 that i'm needing to fix a couple of problems with... the main problem is that it is using an old CStr unit written by a Todd Holmes back in 1993... this unit was written to suppliment the reading and writing of "C strings" to/from streams and converting "C strings" (aka null terminated strings) to/from PASCAL strings...

i started using this unit because i did not understand pointers and PChar all that well back then... it was the first thing i attempted to use that worked for the task at hand... now i'm needing to switch it to using BP7 native routines so that i can add a few capabilities that are sorely missing... the main one being to replace (sub)strings within a PChar string... i've looked for a replacestr or strreplace or stringreplace function but have not had any success... what i have found seems to be targeted at methods and uses quite unnecessary for this plain old DOS command line tool... definitely no turbo vision or anything so elaborate...

so... does anyone have a freely usable BP7 compatible routine that will perform this (sub)string replacement task with standard BP7 PChar strings?

further clarification: i would like to convert this tool to FPC but, as noted, it is a plain old DOS command line tool... IIRC, the DOS FPC requires some sort of memory manager to be used but that would seem to be a lot of overkill for this simple tool... quite simply, the tool pulls preformatted null terminated strings from a proprietary data file and creates an ascii text file with the contents... the final result is that this text file is displayed via html so certain characters '<', '>', and '&' (at least) need to be replaced with their html entities... that's what the stringreplace routine i'm looking for will be used for... i just need to get away from the currently used CStr unit and switch to using BP7's native PChar routines to be able to do so...

any help is appreciated and thanks for reading this quite possibly rambling post emanating from my scrambled brain cells...

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; even if you do, trunk with the plain 16-bit msdos support might still do it for you). What is the exact execution environment where you intend to use the compiled program (operating system, CPU type)?

- 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, 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).

Tomas

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.

this is rather true and i forgot to prefix my subject line with OT... my apologies for that...

but i'm not really asking for non-FPC code to do this, though... at least, i don't think i am... just code that will work with BP7 until i can convert this to FPC DOS code... i certainly don't need access to huge amounts of memory... 64k in the heap is more than enough for this tool and the way it functions... the KIS principle at work :)

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.

true but i'm hoping that someone still has their old libraries available and code to do this that they are willing to share... not to mention that BP7 is only one step away from delphi 1, unless i misunderstand things...

in any case, how is a PChar string that much different than FPC's current use of
pointer based null terminated strings on the heap?

On 02/19/2014 03:06 PM, waldo kitty wrote:
...

any help is appreciated and thanks for reading this quite possibly rambling post emanating from my scrambled brain cells...

FPC DOS is pretty easy for a console program, but it is 32-bit (whereas DOS is 16-bit) so it isn't as simple as Turbo Pascal.

I think my most enjoyable work ever was during the past 3.5 years, using Turbo Pascal on expensive real-time embedded equipment.

There is a 5 MB zip here that should make it easy to get started with FPC for DOS:
http://www.turbocontrol.com/helloworld.htm

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!

yes, that's what i'm seeing, too... i mean, the coding isn't a real problem... but trying to handle data from old 16bit applications can be problematic in some cases...

I think my most enjoyable work ever was during the past 3.5 years, using Turbo Pascal on expensive real-time embedded equipment.

i still get a lot of enjoyment with what i do with my old TP6 and BP7 installations... but i stay very basic in them for the most part... only rarely have i used PChar (for example) or similar constructions... i have been having fun with a new app i've been playing with for several years that's written completely with FPC... lots of pointer suff for strings and lists being used there... switching gears between the two ""styles"" is rough at times :)

There is a 5 MB zip here that should make it easy to get started with FPC for DOS: http://www.turbocontrol.com/helloworld.htm

thank you, sir! i shall take a look :)

Please let me know if it helps. Simplicity seems more valuable to me all the time! :)

A week ago I shared with another Delphi programmer the info below about my recent Turbo Pascal project (and a little bit more).

****************

I was able to have (a single set of) source code that was used for about 15 versions of about 6 different products. One batch file called about 15 batch files (one for each product/version) that compiled the source and compared the resulting executables against what had been shipped. I've done similar things before (but never had so much technical fun): http://brenemanlabs.com/SrcCtrl.htm

Every since C# got popular I enjoy meeting programmers who don't know much about Delphi. Look at the 6th message in this thread if you want to see my normal response:
http://www.control.com/thread/1294638212

The bottom of this page has a little of my APro history: http://turbocontrol.com/APro.htm
Last month Embarcadero mentioned AsyncPro on their "devices and gadgets" XE5 seminar. I'm hoping to upgrade some of my APro examples soon.

This entry in the wiki page for the 16-bit compiler contains a link to another page where seems to be mentioned how the cross compiler can be build on Windows and also the tools required:
http://wiki.freepascal.org/DOS#Snapshots

Regards,
Sven

I recently turned up some interesting stuff about Turbo Pascal, so wanted to add it here in case it might be of help.

Here I can purchase source code (for $200) to make my own Turbo Pascal compiler for DOS (I don't plan to purchase):
http://turbo51.com/compiler-design/tpc16-turbo-pascal-compiler-written-in-turbo-pascal

The same guy has put a bit of effort into these pages: http://turbopascal.org/
http://turbopascal.org/turbo-pascal-download - see 3 PDFs at the bottom http://turbopascal.org/sitemap - could look up TP bugs here?