String corruption, or something else?

[Clay Clear]

I recently tried to convert an ASM UNIT (PB/DOS 3.5) to an OBJ
written with MASM 6.14. On the OBJ file's code getting to the
line with "call GetStrLoc", the program aborts and Windows gives
the "...has performed an illegal operation...please restart your
computer..." error message. I have gone back to the UNIT version
until I figure out WHY this is happening. In other words, I no
longer have the OBJ ASM code to provide as an example. I compiled
the OBJ file with the line: "ml.exe /c gp001.asm". Up until about
10 months ago, I was making VERY heavy use of OBJ files, and I do not
THINK that my current problems are caused by my implementation in
the OBJ file's code, as I am well experienced at manipulating
dynamic strings in OBJ files created with MASM 6.14. However, that
possibility does, of course, exist.

So, what could be causing this? I worked on the problem for 10 hours
a couple of days ago, and no variation of code resolved it. Could it
be caused by a corrupt PB/DOS installation, requiring me to reinstall?
Hopefully, it isn't caused by a corrupt MASM install, as those setup files
are VERY hard to find on the 'Net, and I no longer have them backed up
to CD (accidentally threw the CD away ).

Any ideas of things to try to resolve it VERY gratefully received.


------------------


[This message has been edited by Clay Clear (edited April 30, 2004).]

[Clay Clear]

Update: I tried the OBJ file, again. This time, I wrote a test EXE
that directly linked the OBJ file, instead of $LINKing the PBL file
in which the OBJ file was contained. The test EXE worked fine. I then
changed the EXE so it $LINKed the PBL file, but the EXE only
called the procedure in the OBJ file. That worked fine also.
The problem seems to occur when the production EXE contains both
the OBJ file procedure and a PBU function, and it calls the
OBJ procedure. Both the OBJ and the PBU files are contained in
the same PBL. Both the sub and the function use dynamic strings.
The sub uses BYVAL strings, and the function uses BYREF strings.
The PBU is mixed BASIC/ASM. The production EXE calls only ONE of
the two, then exits.

I have had problems in the past with mixing OBJ/PBU calls in the
same EXE. At the time, I attributed it to my implementation. Now I
am wondering if it's a problem with the PB/DOS 3.5 compiler? These
problems only occurred when calling subs/functions that used strings.
ALL of my procedures/functions, whether OBJ or PBU, use dynamic
strings.

Note that the current problem does not occur if the OBJ file is recoded
as a PBU instead of as an OBJ.

Anybody have any insights?

ADDED: I just realized that well over a year ago I was heavily using OBJ
files to add LFN support for file I/O to my PB/DOS EXE's. I do not
recall having this problem when using strings in the OBJ subs/functions, and
I am quite sure that at least some of my EXE's also used PBU subs/functions
that also used strings. So, the question NOW is, can anybody think of
anything in my setup that may cause this "new" OBJ/PBU problem? If needed,
I can post my full include-in-all-BAS-files INC file (it is also included in
the PBU BAS files). The INC file is nothing but all of the DECLARE's,
TYPE definitions, equates definitions, etc. It also includes all of the
metastatement settings. I have made a number of changes in my "master"
setup over the past 8 months, and cannot coherently recall anything
that would stand out as causing this current problem with OBJ files.


------------------




[This message has been edited by Clay Clear (edited May 01, 2004).]

[Clay Clear]

Problem resolved! The problem WAS caused by something-or-other in my
metastatement usage in my include-in-all-BAS-files INC file.
What I did that fixed it was to move the metastatements into two INC
files, one for EXE's and one for PBU's. Then, in the PBU one, I
stripped out all statements that I figured only needed to be
set in the main EXE. Then I recompiled. Works like a champ, now!


------------------