HTML Tidy

This Tracker item was closed automatically by the system. It was
previously set to a Pending status, and the original submitter
did not respond within 999 days (the time period specified by
the administrator of this Tracker).

Applied your patch except for the tidy.c part that will produce some
"unreachable code" warnings with some compiler.

Geoff,

Thanks you for the head-ups. This is now fixed.
I think they are some @xx in tidy.def to help interfacing with languages
that are not case sensitive such as Delphi.
In any case, it is better to have tidy.def in the distribution rather than
having several incompatible ones lying around.

I will come to this patch later when time allows.

Friday, 05 January 2007.

Hi Arnaud,

Re: http://tidy.sf.net/patch/1606194

As a quick test I converted the dsw and dsp files to unix line endings,
and yes, while MSVC loads the tidy.dsw ok, it reports the dsp files as
corrupt. Why the DSW parser has no problem with unix line endings, while
the DSP parser does is, of course, a Microsoft mystery ;=))

Just to make sure, I downloaded and applied my tidycvs02.txt patch to a
new, updated today, copy of tidy cvs in a tidycvs02 folder, and it loaded
fine in MSVC6, and built fine, except for two small corrections in the NEW
tidy.def file - although I had to chop some LF chars off the end of
tidycvs02.txt ... not sure how they got there ...

The small corrections to tidy.def were -

(a) the NAME of the DLL, following the reserved word LIBRARY - this is not
too important since MSVC uses an /OUT link command to set the output name,
which will override the DEF statement anyway, but why not use the name that
is used, namely libtidy, and

(b) there is no function 'tidyBufAllocWithAllocator', although it is
DECLARED in buffio.h so have commented it out of the DEF using a ';' - you
may want to remove it from both the DEF file, and buffio.h - or of course,
add a function in buffio.c ...

But more importantly, this DSW/DSP set of modified files also loaded fine
into MSVC7.1 and MSVC8, and after 'conversion' builds cleanly - no errors
or warnings.

Well, MSVC7 issues a linker warning on Tidy and TidyDLL Debug
configuration, about an option conflict, namely -
LINK : warning LNK4075: ignoring '/EDITANDCONTINUE' due to
'/INCREMENTAL:NO' specification, but this seems VERY benign, and I ignore
it. It can be removed by changing the incremental link option to either
'yes', or 'default'.

As a matter of interest, here are the WIN32 release EXE sizes with MSVC6,
MSVC7 and MSVC8 respectively -

286,720 tidycvs026.exe
274,432 tidycvs027.exe
290,816 tidycvs028.exe

I am often 'surprised' by the more than 10K difference in these three
'Release' versions, 6, 7, and 8 ... MSVC7.1 produces the smallest - and
this is using optimisation /O2 (for speed) and I did not try other
optimisation options ...

I again tried briefly to get the nmake make files, namely makedll.vc6 and
makefile.vc6 to work, this time using a MSVC6/7 command prompt environment.
I had previously tried them in a MSVC8 prompt, using the latest PSDK
(Server 2003 R2). While again makedll.vc6 does its thing fine, makefile.vc6
failed. I suspect this is because of a mixture of version 6 and version 7
system include files (through SDKS).

MAYBE I could get this to work if I very carefully massaged the
environment, but decided not to spend more time on this ... I did NOTE the
output from the makedll.vc6 file is into a 'bin' folder, which maybe
answers why originally the alltest.cmd used bin\tidy.exe ... but that is
not true for MSVC builds, although they too could be set to output to a
'bin' folder ...

Using a single 'bin' folder is GOOD for building and running a DLL
version, since the DLL (shared library) can reside in the same folder as
the executable. But one of the main 'problems' in using a single 'bin'
folder, is how to separate the Release from the Debug build configurations.
One common open source solution for this is to append a 'd', or even a '_d'
to the debug builds ... then they can all reside separately in a 'bin'
folder together ... but have done nothing about this ...

Anyway, I attach a new tidycvs02a.txt, in a tidycvs02a.zip file, but it is
the same, except for the order of the diffs, and the addition of tidy.def
changes ... and, as now usual, the zip also includes all the complete
changed files ...

You seem to have worked out that using a DEF file requires only its
creation, using the MS rules in -
http://msdn2.microsoft.com/en-us/library/28d6s79h.aspx - and inclusion in
the tidydll.dsp source file list, as you have done, and MSVC will do the
rest ... but I am unsure what we have gained by this, except that the
functions also now have an 'ordinal' number assigned ...

As the MSDN page states - '.def files are generally not necessary.'. With,
or without the DEF file, functions like 'tidyCreate' are exported by the
DLL, in the LIB (arch) created, as '_tidyCreate@0' and
'__imp__tidyCreate@0' ... that is with 'decorations' ... this '@0' denotes
it is a function using __stdcall where the callee performs the stack
cleanup, versus __cdecl where the caller cleans up the stack ... But all
this 'decoration' is fully handled by most compilers/linkers ...

Back in March 2006, http://tidy.sf.net/issue/1459819, not sure exactly
what Robert's problem was with Delphi, which he suggests does not use the
'exported' from-the-DLL library, which is almost unaffected by this DEF
file anyway, except to add ordinal numbers ... how can Delphi resolve
external links without using this LIB is unknown ...

It is true the DEF file adds the 'undecorated' names to the 'export'
section of the DLL, that is _tiydCreate@0 becomes just tidyCreate, etc, and
this IS required if you want to manually load the DLL, using a Windows
system call, LoadLibrary('dllname'), and 'search' the DLL for the exported
functions using the function 'name' in GetProcAddress() ... maybe this is
what Delphi does?

This 'manual' DLL loading is good if you want a process to continue even
if it does not find the DLL at runtime ... when a process 'statically'
links to a DLL, using the LIB built from the DLL, the OS does the DLL
loading, and address fix-ups, and thus will abort if the DLL is not found
in either the path of the EXE, or in any other path from the PATH
environment variable ...

Anyway, adding a DEF file also does no particular harm, except perhaps
increase our file maintenance a tad ... any changes in API function names
must be also changed in the DEF file ...

Hope this gets these small MSVC8 issue into cvs ...

Regards,

Geoff.

attached: tidycvs02a.zip containing tidycvs02a.txt, build\msvc\tidy.dsp,
build\msvc\tidy.def, console\tidy.c, include\platform.h, build\readme.txt,
build\msvc\MakeDLL.vc6

File Added: tidycvs02a.zip

Geoff,

My problem with the *.dsp file may come from the fact that they are in
UNIX text format. I have not checked yet.

Do you know how to make use of a .DEF file in the project files ? (see
http://tidy.sf.net/issue/1459819)

How do you load the *.dsp files provided with tidy within MSDev 6.x ? It
fails for me.