Board index » off-topic » Re: QC 8386

Re: QC 8386


2007-03-16 09:26:24 PM
off-topic2
Quote
I have tested building app with the long descriptions that are shown
in the report, and when I look at the version information for the apps
or query it programmatically I see the correct results with no garbage
characters.
Using Project|Options|VersionInfo form the IDE doesn't cause a bug, but a
manually created .rc file that is included in the project does. As brcc32 is
called to create the res-file and this (buggy) res-file is then linked to the
final exe also the exe exhibits the same corrupted strings.
Yes, it could be that the linker fixes the buggy res-file and makes up for what
brcc32 did wrong...
However that the bug really is within brcc32 can be seen from the following
project in the attachment-group:
Example project for QC 8386 (Res-file bug)
It is a minimal Delphi-project, the rc-file is the one from the QC report (maybe
there is a shorter rc-file that also causes the bug).
Build from within the IDE and then doing your number 2 suggestion:
Quote
2. When you use windows explorer (file properties) to look at the
version info for the app it displays incorrectly.
you can see that "Company Name" is not what it should be.
Regards, Maël.
 
 

Re:Re: QC 8386

Maël Hörz wrote:
Quote
Example project for QC 8386 (Res-file bug)
Thanks. I'll look at it as soon as I have a chance.
- Leo
 

Re:Re: QC 8386

Maël Hörz wrote:
Quote
However that the bug really is within brcc32 can
be seen from the following project in the attachment-group:
Example project for QC 8386 (Res-file bug)
The problem is cause by the format of the rc file. See the comment and
working rc files that I attached to the original qc report.
The original rc file would not even open in my resource editor until I
made corrections to it. After I formatted properly (two different ways
shown in the two files I attached) it opens correctly in the resource
editor and also works correctly in BDS.
- Leo
 

{smallsort}

Re:Re: QC 8386

Let me check if I find my own rc-file that caused the bug and see if it is only
CR/LF issue.
But still MSVC open the source.rc file ok and displays everthing right, so this
is IMO a bug in brcc32.
 

Re:Re: QC 8386

Okay, I tested it with my rc-file.
Double CRLF don't change anything but adding \0 works indeed.
Though this *is* a bug, since all version of VC++ I tested can open the rc-file
without \0 appended and produce correct version info in the exe-file. And on top
of that the rc-files generated by VC++ don't append \0 , so it should be
possible to compile such simple rc-files.
I really don't see a point in closing as test case error, as it isn't a test
case error, but a basic failure of handling rc-files as generated by most tools
(including VS 2005) , i.e. without \0
I could though provide my rc-file, as double CRLF don't avoid the bug to appear.
 

Re:Re: QC 8386

Maël Hörz wrote:
Quote
But still MSVC open the source.rc file ok and displays
everthing right, so this is IMO a bug in brcc32.
It's not a bug to not match exactly the way some ms product works. In
many of the ms specs they require a group of strings to be terminated
by two 0 bytes to signify end of a record. How can you fault
Borland/CodeGear for following this? Resource Builder - a resource
editor that I downloaded also rejects the incorrect rc file.
Also, the report was filed almost three years ago and yours are the
first comments on it.
- Leo
 

Re:Re: QC 8386

Maël Hörz wrote:
Quote
Though this *is* a bug, since all version of VC++
BDS 2006 does not import VC projects to the best of my knowledge. If
there is in import facility in the IDE and it fails, then a report
should be filed on that failure if one has not yet been filed.
Beyond that, if a VC generated file does not work in BDS, then you
need to find a way to convert it. As far as version info is concerned,
why would anyone even want to import a version info rc from VC? BDS
handles version info directly in the project options dialog. Doing so
works and gives you access to changing or auto-incrementing the
version number.
If you are converting a VC app to be compiled in BDS, then you will
probably have to either edit the rc script to match the spec or add
the version info in the correct place in project options.
If you want something that works exactly like VC does, then I suggest
that you buy VC. If you want something that works better, use BDS.
- Leo
 

Re:Re: QC 8386

Quote
If you want something that works exactly like VC does, then I suggest
that you buy VC. If you want something that works better, use BDS.
I don't want something that works like VS. I sometimes use VS and own it, still
I use Delphi the most.
If people report me issues like this in software I created I never tell them to
go look elsewhere, especially since it is a triviality to fix the issue
(automatically insert a \0 before the last ") and beeing more compatible is for
sure a good thing!
I found a way to fix the issue some time ago for me, but I really have to say I
dislike it *very much* if people block and reject obvious bug reports, and
report it as test case error (which it isn't). Attitude like this does harm
CodeGear, and there are many bug reports nobody cared for since such bugs
(especially tricky ones like this) are annoying to report and to search.
There are quite a lot of (year) old bug reports that never were fixed, which is
a bad way to treat customers (even if you are not an employee of CodeGear, you
moderate it and influence the perception of CodeGear).
This special thing might not be of importance for many, but just because it
doesn't crash your app doesn't mean it shouldn't be fixed. Such attitude gives a
more than bad impression...
And also this VS vs. BDS thing, and use VS if you don't like BDS, ... tiring and
annoying.
 

Re:Re: QC 8386

Quote
Resource Builder - a resource
editor that I downloaded also rejects the incorrect rc file.
ResourceHacker imports it and VC++ too (VC++ is the reference when it comes to
rc-files, since MS are the one how defined rc files). And apart from that I
thought external tools were not valid as argument (by your definition) ...
Quote
Also, the report was filed almost three years ago and yours are the
first comments on it.
This is a tricky bug people probably wouldn't know how to track down (or take
the time to), nor to search for "brcc32" nor care to report.
That many bugs were ignored and not fixed in the past is nothing to praise, I
think there were enough complaints about this. Just a guess, but it might
influence peoples will to report or comment ... ;-)
 

Re:Re: QC 8386

Maël Hörz wrote:
Quote
report it as test case error (which it isn't).
A test case error means that the user is not using the product as it
is designed to be used. There is a documented way to add version
information to a BDS project - use the project manager. If you do that
it works properly. So this _is_ a test case error.
The report is based on doing something completely different - using a
resource script created by a different tool and adding it to the
project. I have seen no documentation that that is supposed to work,
and have provided information on how to correct the script so that it
can be used.
If you don't want to change the script, then adding the res file
created by the third-party software also works.
Quote
There are quite a lot of (year) old bug reports that never were fixed,
Which is exactly why, as a user of BDS, I have volunteered to serve as
a sysop and try to help clear up the backlog. Good progress has been
made in the time I have been helping with this. By sending a report
like this to the internal system at CodeGear I would only be impeding
that process.
With the release of BDS 2006 Borland had already decided to drop
support for MFC and they do not provide support for importing other VC
oriented files. This was a conscious decision based on the limited
value for such efforts. Maybe when the actual bugs in the product are
fixed, they can reconsider that decision.
Quote
This special thing might not be of importance for many,
but just because it doesn't crash your app doesn't mean
it shouldn't be fixed. Such attitude gives a
If something were broken, I would agree that it should be fixed. In my
opinion only the referenced qc report is broken. If one of the other
hundred or so other sysops disagrees with me, the report will be
opened, but I see no one but you arguing for that to happen.
I have already wasted more time than is reasonable on this, and the
issue is closed as far as I am concerned.
- Leo
 

Re:Re: QC 8386

"Leo Siefert" < XXXX@XXXXX.COM >wrote in message
Quote
Which is exactly why, as a user of BDS, I have volunteered to serve as
a sysop and try to help clear up the backlog. Good progress has been
made in the time I have been helping with this. By sending a report
like this to the internal system at CodeGear I would only be impeding
that process.

SysOps are given very clear guidelines from QA and R&D
about what makes for a good report. Clear steps and all that.
If he promotes a report like this, he risks getting reprimanded
by QA and, if there are a few cases like this, possibly losing
his sysop status.
Thus, I'm sure you can understand that any sysop has to have
confidence that they can defend opening any particular report
before they will open it.
Leo has a pretty good idea about what R&D will say about
any particular report because they already have on a number
of similar reports. We don't get to listen in on that conversation,
so all we hear is Leo being "obstinate" about refusing.
Now, I don't have any problem with you arguing your case
as you have. If you could have given Leo a good argument
for opening it, he would have had ammunition for defending it.
That didn't work out in this case, but you gave it a good shot.
--
HTH,
Brad.