Building TidyATL.dll

in page links: prerequisite building fix-ups testing error trail success callback configurations proof downloads diff MSVC6 end

After a recent Tidy Support Request ( ), on the Tidy wrappers, I decide to try to build this neat set of wrapper 'components' using MSVC8 (Microsoft Visual Studio Express Editions - FREE!) ... while I succeeded in building, and registering a TidyATL.dll, initially I could NOT get it to successfully run, either in Visual Basic, nor in Visual C# ;=(( But after recompiling the TidyATL source using __stdcall (/Gz) it started to work, and after renaming the callback, that started to work as well, but have left all the noisy effort finding this ...

The source can be downloaded, thanks to Charles Reitzel, from :-
But first, the prerequisite ...


Of course you need the tools - MSVC8 mentioned above, the Microsoft (MS) PSDK (Platform Software Development Kit), the Windows DDK (Device Driver Kit) - more DDK details below. And for the test applications, MS Visual Basic, and MS Visual C# ...
And of course a CVS client to download and update the sources.

SOURCES & FOLDERS: 1. HTML Tidy and 2. Tidy Wrappers

1. HTML Tidy:

The first source to download and build the standard HTML Tidy from :- 
Or more precisely, the CVS source download instructions from :-

At lease the static libtidy.lib must be built, as the Tidy wrappers link with this static library. In my case I built the following folders :-
To maintain a 'relative' folder access, I then COPIED the wrapper sources for building into :-
<some_root>\tidyatl  - subject of this build
<some_root>\twperl  - not yet built.

2. Tidy Wrappers:

This page give the CVS download instructions for the Tidy Wrappers :-

First setting the environment variable CVSROOT to the 'root' folder I am using, C:\FGCVS, but here I am showing just <myroot> - you should choose your own root folder name - like :-

> set CVSROOT=c:\fgcvs

Then the instructions I used were : (Enter key for password)
cvs login
Then in a folder <myroot>\tidywrap I did each of the following :-
cvs -z3 co -P tidyatl
cvs -z3 co -P include
cvs -z3 co -P twperl
cvs -z3 co -P www
This downloaded the sources into their respective folders.

I NEVER build in these DOWNLOAD, and UPDATED CVS/SVN source folders, but ALWAYS copy it to another location to do the actual building ... grace of the growing size and declining price of hard disk space ;=))

top -|- end

Building tidyATL.dll

Naturally in the downloads below I have now include a tidyatl/tidy.sln, which has two projects, tidyatl/tidy.vcproj and tidycom/tidylib.vcproj, but you must still get the relative folder arrangement right. But this is my build story, starting with the MSVC6 dsw/dsp build files ...

As indicated above, I copied the downloaded CVS source from its download folder, to :-
This is so that I can have relative folder access to the libtidy.lib, in :-

On loading tidyatl/tidy.dsw into MSVC8, and instructing it to 'convert all', I got an error, that tidylib.dsp could not be loaded. The error babbles about the file 'perhaps being corrupted', but it is simply not in the path given in the dsw file.

The default path in the DSW file is :-
Project: "tidylib"=..\..\tidy\build\msvc\tidylib.dsp

If you have built the 'prerequisite' mentioned above, then you just delete this project from the solution, and add a new existing project, by loading your tidylib.vcproj, which in my case is in -

Also to get the correct build order, it is necessary to make the ATL project dependant on this tidylib project. Of course, at this point you can try a build. If your tidylib is recent and up to date then only the Tidy ATL project should commence. It is likely that it will fail, missing say tidyenum.h, unless you by coincidence have this in :-

This 'tidy include' location need to be 'fixed' in several places, like :-
Tidy Property Pages -> Configuration Properties -> C/C++ -> General -> Additional Include Directories, and
Tidy Property Pages -> Configuration Properties -> MIDL -> General -> Additional Include Directories.

If you are using the SAME directory structure as me, then this becomes -
Note the use of a relative path, rather than a 'fixed' one ... but it does not make much difference.

Since you have created a dependence on tidylib, then the linker will already include something like -
where $(IntDir) is either Debug or Release, in some configurations, but it is safer to explicitly add the libtiyd.lib, and the appropriate path to each configuration you want to build. After trying various configuration, I eventually settled on 'UNICODE Debug', for my first build and testing, but this is optional ...

top -|- end


Due to the changed, tighter, or difference type casting of MSVC8, I had to make some relative minor adjustments to the code. The diff file is given below. As can be seen this is mainly ONLY providing some type casting, and few small fixes for UNICODE.

Also one link, I got an error :-
LINK : fatal error LNK1104: cannot open file 'atlthunk.lib'

Luckily, I had already installed a (maybe previous) Windows DDK, (Device Driver Kit) thus had this library available in :-
This path I added to Tools -> Options -> Projects and Solutions -> VC++ Directories -> Show directories for: -> Library file. The latest DDK at this time (2007/09/18) appears to be Windows Server 2003 SP1 DDK, which requires the 236MB ISO file be burned onto a CD-ROM for installation. This can be done using ISO Recorder, or BURNCDCC.

I got 4 warnings like -
.\Tidy.def : warning LNK4222: exported symbol 'DllCanUnloadNow' should not be assigned an ordinal
which I ignored for a while, but later I removed these ordinal numbers from the Tidy.def file...

There is a Custom Build step which does the registration. This places an entry in the Registry, such that the COM object can be explored with oleview.exe ... select and expand the type libraries, and scroll way down to the 't' ... you should find Tidy 1.0 Type Library (ver 1.0) nicely sitting there. If it is NOT then something has gone wrong with the 'registration' step, which is NOT done if there is a build error. And that will probably means you can not find it in Visual Basic or Visual C# when adding a 'reference' ...

This was the Debug build, so I switched to Release, but discovered there are multiple release build, thus made the same path changes to each. I was unable to build 'Release MinSize', since this defines _ATL_MIN_CRT, which duplicates malloc, calloc, etc, which then gives a fatal link error :-

------ Build started: Project: Tidy, Configuration: Release MinSize Win32 ------
LIBCMT.lib(calloc.obj) : error LNK2005: _calloc already defined in StdAfx.obj
LIBCMT.lib(realloc.obj) : error LNK2005: _realloc already defined in StdAfx.obj
.\Tidy.def : warning LNK4222: exported symbol 'DllCanUnloadNow' should not be assigned an ordinal
.\Tidy.def : warning LNK4222: exported symbol 'DllGetClassObject' should not be assigned an ordinal
.\Tidy.def : warning LNK4222: exported symbol 'DllRegisterServer' should not be assigned an ordinal
.\Tidy.def : warning LNK4222: exported symbol 'DllUnregisterServer' should not be assigned an ordinal
Creating library .\ReleaseMinSize/TidyATL.lib and object .\ReleaseMinSize/TidyATL.exp
ReleaseMinSize/TidyATL.dll : fatal error LNK1169: one or more multiply defined symbols found

I removed the 'ordinal' values from Tidy.def, and was able to build 'Release MinDependancy', with similar LINK warnings, and a NEW one, but it built, with a severe warning :-

LIBCMT.lib(calloc.obj) : warning LNK4006: _calloc already defined in StdAfx.obj; second
definition ignored
LIBCMT.lib(realloc.obj) : warning LNK4006: _realloc already defined in StdAfx.obj; second
definition ignored
Creating library .\ReleaseMinDependency/TidyATL.lib and object
ReleaseMinDependency/TidyATL.dll : warning LNK4088: image being generated due to /FORCE option;
image may not run
Embedding manifest...
Performing registration

Note the COM DLL registration is done automatically - see 'Performing registration'. I then tried the UNICODE configurations, again sometimes fixing the paths, and built a UNCODE version of the ATL (COM) library. I used the 'UNICODE Debug' configuration for all the testing, but could never get the JIT debugging to kick in despite lots of effort ;=((

I later settled on a set of four(4) configurations. See configurations below ...

top -|- end

Testing TidyATL.DLL

I tested TidyATL.dll using BOTH a Visual Basic project, and a Visual C# project. In the downloads I have now provided the full sources and version 8 solution files for each of these. But I was starting with a version 6 source, so there are some gory details ...

Thankfully there is a small Visual Basic project to act as a test. First this had to be converted from MSVB6 to MSVB8, and some problems were reported. Many could be easily fixed, but I was quite puzzled by the error that -
Private WithEvents tdoc As TidyATL.TidyDocument
tdoc = New TidyATL.TidyDocument
FAILED. I had added the reference to 'Tidy 1.0' COM component, so why was this an error?

Maybe again this is just a 'version' thing, because changing these lines to -
Private WithEvents tdoc As Tidy.Document
tdoc = New Tidy.Document
got over this problem.

Also initially the Browse for HTM/HTML files failed to show the test foo.html file present, but this turned out to be due to the fact that the filter string had been separated with a comma (,) instead of a semi-colon (;). This fixed, and the OpenFile dialogs worked well. I also added an [ Exit ] button, since I do not like to leave people to just jump on the top right big red button to exit an application. And I add some protection from pushing certain buttons when there was say not input file given, and not loading a config file if none was given, but this still left me with a persistent CRASH.

This turned out to be in the -
stat = tdoc.RunDiagnostics()
call. By commenting out this call I was able to get through the tidying ;=)) There also seems to be a problem with the callback to the message posting mechanism. Anyway, it works, sort of ;=))

I then used the code given in the Feature Request to create a C# project, but ran into something of the SAME ERROR ;=((

top -|- end


One consistent error I got was :-

persistant error

This was in a C# program, but I get the same when I call -
in Visual Basic.

I can understand the idea - the function is __cdecl and I called using __stdcall, or vice versa BUT HOW TO FIX THE PROBLEM???

The functions are declared as -

   STDMETHODIMP CTidyDocument::RunDiagnostics( int* status ) {
   *status = tidyRunDiagnostics( _tdoc );

From the WIN32 PSDK headers ...

   #ifdef _WIN32 // Win32 doesn't support __export
   #define STDMETHODCALLTYPE __stdcall

Ok, that looks ok ... then in libtidy.lib - in tidy.h

   TIDY_EXPORT int TIDY_CALL tidyRunDiagnostics( TidyDoc tdoc );

Then in platform.h ... under the appropriate section ...

   # define TIDY_CALL __stdcall

By fiddling with the TidyATL.dll code, I have narrowed it to the call to tidyParseBuffer. I have also tried tidyParseString, but with the same error ...


View of 2nd error dialog


top -|- end

Chasing the TRAIL ;=))

My C# program calls -

   status = tdoc.ParseString ( HTMLtext );

This arrives in TidyDocument.cpp

   STDMETHODIMP CTidyDocument::ParseString (BSTR content, int *status)

which does -

   TidyBuffer buf = {0};
   tidyBufAttach( &buf, (byte *)content, ::SysStringByteLen(content) );
   *status = tidyParseBuffer( _tdoc, &buf );

After being reminded that TidyBuffer buf = {0}; is not the correct initialization, I changed this to -

  tidyBufInit( &buf );
  tidyBufAttach( &buf, (byte *)content, ::SysStringByteLen(content) );
  *status = tidyParseBuffer( _tdoc, &buf );

In tidylib.c, this is :-

   int TIDY_CALL tidyParseBuffer( TidyDoc tdoc, TidyBuffer* inbuf ) {
     TidyDocImpl* doc = tidyDocToImpl( tdoc );
     return tidyDocParseBuffer( doc, inbuf ); }

tidyDocParseBuffer is -

   int tidyDocParseBuffer( TidyDocImpl* doc, TidyBuffer* inbuf ) {
     int status = -EINVAL;
     if ( inbuf ) {
      StreamIn* in = TY_(BufferInput)( doc, inbuf, cfg( doc, TidyInCharEncoding ));
        status = TY_(DocParseStream)( doc, in );
     return status;

BufferInput does

   StreamIn* TY_(BufferInput)( TidyDocImpl* doc, TidyBuffer* buf, int encoding ) {
     StreamIn *in = TY_(initStreamIn)( doc, encoding );
     tidyInitInputBuffer( &in->source, buf );
     in->iotype = BufferIO;
     return in; }

This assert is in DocParseStream ...

   int TY_(DocParseStream)( TidyDocImpl* doc, StreamIn* in )  {
     Bool xmlIn = cfgBool( doc, TidyXmlTags );
     int bomEnc;
     assert( doc != NULL && in != NULL );
     assert( doc->docIn == NULL );
     doc->docIn = in;


   TidyClearMemory( doc, sizeof(*doc) );

which is -

   0046394C push 0A98h
   00463951 push 0
   00463953 mov eax, dword ptr [doc]
   00463956 push eax
   00463957 call @ILT+6630(_memset) (45C9EBh)
   0046395C add esp,0Ch

I tried REMOVING the assert, in TWO(2) places in libtidy code ... of course, such 'asserts' only effect the debug version. In most compilers, asserts are 'nothing' in a Release build.



top -|- end


Boy do I HATE it when you make 2 changes, and then it works! You then never know which it was that 'fixed' the problem ;=/.

I found how to sign the assembly, and put it in the 'Global Assembly Cache' - see the forum post for details - and the 2nd thing was I recompiled both the Tidy and libtidy switching to :-
Configuration Properties -> C/C++ -> Advanced -> Calling Convention to __stdcall (/Gz).

I then got a warning that 'main()' had to be __cdecl so I added this to main, and RECOMPILED BOTH the libtidy and TidyATL.dll - AND IT WORKED!  Well mostly! I later proved it was all due to the 2nd action, since I used gacutil to delete the Tidy2.dll I had put in the 'Global Assembly Cache' ...

I added the foo.tidy configuration file, with contents exactly per the 'Feature Request' :-

clean: yes
bare: yes
input-encoding: utf8
output-encoding: utf8
word-2000: yes
tidy-mark: no
DocType: omit
output-html: yes
show-body-only: yes

Not sure why word-2000: yes is there, since this is NOT a word document. Also since ALL text within a Visual Studio C# program is in UNICODE, and TidyATL 'knows' this, and forces the encoding change before passing the string, thus not sure why the 'encodings' are added here. Also, since it is show-body-only: yes, not sure why DocType: omit, and tidy-mark: no are there. And finally output-html: yes is the default action, but I used it 'as is' ;=))

After the Tidy action, the file, foo.errors.txt, contains the following entries :-

line 1 column 1 - Warning: missing <!DOCTYPE> declaration
line 1 column 1 - Warning: inserting implicit <body>
line 1 column 1 - Warning: missing </span>
line 1 column 1 - Warning: inserting missing 'title' element
Info: Document content looks like HTML 4.01 Transitional
4 warnings, 0 errors were found!


At least for the C# project. Now to try the Visual Basic project ...


Compiling it all with __stdcall (/Gz) did the trick! I added an INI file read/write to the project, so it would 'remember' the files last loaded, mainly to speed up the 'testing' process ... what FUN I had over the last few days getting this to work, but now it does one wonders what all the fuss was about ;=))

top -|- end


But the 'warning and error event callback' was NOT working in Visual Basic? How to get that too functioning? As usual, this turned out to be EASY ;=)) I had seen several cases where the 'naming conventions' had changed between VB6 and VB8. Some simple examples are :-

For example, the VB6 statement :-
 Private WithEvents tdoc As TidyATL.TidyDocument
 Private WithEvents tdoc As Tidy.Document
in VB8.

Even simple things like, in VB6 :-
 If level = TidyInfo Then
became the BIG in VB8 :-
 If level = TidyATL.__MIDL___MIDL_itf_Tidy_0000_0009.TidyInfo Then
and MANY others, so why NOT the CALLBACK function ...

Sure enough, VB8 wants this called - tdoc_OnMessage1( ... ) Note it is just a '1' added, but it make all the difference in the world ;=))


Now some more gory details as I tried to track this down. The code in TidyATL is there, in TidyDocument.cpp :-

HRESULT CTidyDocument::FinalConstruct() {
  _tdoc = tidyCreate();
  tidySetAppData( _tdoc, (void *) this );
  tidySetReportFilter( _tdoc, ReportFilter );

Then the 'ReportFilter' function :-

Bool CTidyDocument::ReportFilter( TidyDoc tdoc, TidyReportLevel lvl,
                                  uint line, uint col, ctmbstr mssg ) {
  CTidyDocument* comDoc = (CTidyDocument*) tidyGetAppData( tdoc );
  if ( comDoc )  {
    BSTR wmsg = A2W( mssg );
    comDoc->Fire_OnMessage( lvl, line, col, wmsg );
  return yes;

This looks fine ... so what is wrong? Of course, in the Visual Basic TidyInputForm.vb, the receiver is declared as :-

Private Sub tdoc_OnMessage(ByVal level As TidyATL.TidyReportLevel, _
       ByVal line As Integer, _
       ByVal col As Integer, _
       ByVal msg As String)

Maybe it should be 'Public' ... How does 'Fire_OnMessage' get to tdoc_OnMessage? Some tough questions ;=)) In TidyCOMPCP.h, one can find :-

  template <classT>
  class CProxy_ITidyDocumentEvents :
       public IConnectionPointImpl<T, &DIID_ITidyDocumentEvents, CComDynamicUnkArray>
     //Warning this class may be recreated by the wizard.
    HRESULT Fire_OnMessage(TidyReportLevel level, LONG line, LONG col, BSTR message)
      CComVariant varResult;
      T* pT = static_cast<T*>(this);
      int nConnectionIndex;
      CComVariant* pvars = new CComVariant[4];
      int nConnections = m_vec.GetSize();
      for(nConnectionIndex = 0; nConnectionIndex < nConnections; nConnectionIndex++)
        CComPtr<IUnknown> sp = m_vec.GetAt(nConnectionIndex);
        IDispatch* pDispatch = reinterpret_cast<IDispatch*>(sp.p);
        if (pDispatch != NULL)
          pvars[3] = level;
          pvars[2] = line;
          pvars[1] = col;
          pvars[0] = message;
          DISPPARAMS disp = { pvars, NULL, 4, 0 };
          Dispatch->Invoke(0x1, IID_NULL, LOCALE_USER_DEFAULT,
              DISPATCH_METHOD, &disp, &varResult, NULL, NULL);
      delete[] pvars;
      return varResult.scode;

And in TidyDocument.h this call is there :-

// CTidyDocument
class ATL_NO_VTABLE CTidyDocument :
  public CComObjectRootEx<CComMultiThreadModel>,
  public CProxy_ITidyDocumentEvents< CTidyDocument >,

So it all looks to be there! Why did it not work? As stated above, VB8 wanted this callback function named tdoc_OnMessage1( ... ), and then it all functioned as desired.

top -|- end


Although all the initial testing was done with the 'UNICODE Debug' configuration, I eventually got around to building, and testing the other configurations. This required excluding the code in atlimpl.cpp. Most of it had already been excluded if _DEBUG was defined, which is why I chose to initially test with the 'UNICODE Debug' configuration, and it seemed no problem if it was ALL excluded.

In fact, after batch build them all, I decided in MSVC8 that 'MinSize' and 'MinDependancy' had little meaning. So I have reduce the MSVC8 solution files to only have four(4) configurations - Release, Debug, UNICODE Release and UNICODE Debug. Feel free to add more if desired. And these are output to the folders Release, Debug, ReleaseU, and DebugU respectively.

The final testing was done on the 'UNICODE Release' configuration. While the COM registration is 'automatic', care should be taken when 'playing' with multiple configuration which one has actually been registered. Also both VB8 and C#8 do an extract of the TidyATL.DLL at startup, and write an Interop.TidyATL.DLL into their respective local space. If you make changes, and change configuration, make sure this 'Interop' DLL is deleted each time to ensure you are in fact using the last build.

Concerning the 'test' folder, I moved the VB6 test into a folder VB6, and added a VB8 and C#8 folders, containing my two test projects.

top -|- end


Just to prove that all problems had been solved I download the 2003 binaries from - From this page I found, which contained an 'assembly' DLL - Tidy.dll, and the source of a C# TestIt program, and, which contained a 2003 TidyATL.DLL, and a VB6 test program, TestTidyCOM.exe, and its source.

I had no need for the 'assembly' DLL, and the TestIt C# program was already very similar to that Perry had posted, except it had more output to the console. I had already covered this 'output' by adding an output to a TempLog2.txt file, to be able to examine the results in detail.

However the, with its 2003 TidyATL.DLL and TestTidyCOM.exe gave me a chance to test and compare.

The 'assembly' DLL, as opposed to the COM DLL (TidyATL.DLL), can be placed in the folder where the VB (or C#) EXE is run, or can be created, signed and installed in the 'Global Assembly Cache', or in some cases it can be compiled into the EXE ... the TidyATL.DLL has to stay in the same place it was when regsrvr32 ran to 'install' it in the registry ...

V#8 (and VB8 for that matter) automatically does the former as soon as you add a reference to the COM type library ... it generates an Interop.TidyATL.dll places it in BOTH the Debug and Release bin folders where it generates the EXE ... and includes this 'dependence' in the compile, automatically ...

Removing, or moving either DLL, the assembly DLL or the COM DLL will cause the C# (& VB) EXE to crash, or at least abort with an error like 'can not load component' ... maybe there is a build option to 'avoid' the local creation of the 'assembly' DLL, like in this 2003 VB EXE, which runs without it, but have not explored this ... yet ...

Thus I TRIED the 2003 TidyATL.DLL just by renaming mine, and putting the 2003 version in its place. Then I do get what I suppose could be called 'funky' characters appended to the output. In HEX, they are :-

C9 81 C8 81 E1 80 80

This is appended to the text ... and now I have a 'definition' of 'funky' - namely, hi-bit characters, or extended ASCII ;=))

But when I put back my MSVC8 compiled TidyATL.DLL, this addition does not appear. So yes, it seems this problem has been solved by later code Tidy code ... 'funky' character output is SOLVED.

Also, when running the 2003 TestTidyCOM.exe I could note that the CALLBACK was working, even with my 2007 TidyATL.DLL. It was this that lead me away from there being a problem with my MSVC8 2007 TidyATL.dll code - that the callback problems must reside in the VB8 program itself. And that led me to using the Visual Basic 'Call Explorer' to discover that the 'callback' had to be named tdoc_OnMessage1(...) ... CALLBACK problem SOLVED.


top -|- end


And to provide some downloads, so others can try, but as usual it is highly recommended that you build your own ...

Download Description Size Date MD5 Tidy Type Library (DLL) - MSVC8 - UNICODE Release configuration. 151,392 18/09/2007 b51e92142054279193b7225cda9eecaa Tidy Type Library (DLL) - MSVC8 - UNICODE Debug configuration. 331,885 16/09/2007 01d1cbfa1426b6b50899d6a317ccdfb9 Visual C++ - v.8 - TidyATL.dll build set, and patch files. 6,657 18/09/2007 6e2ada5bd6f82e3884adeec054de55fe Visual Basic test application source, include v.8 solution build set. 13,668 18/09/2007 eb95dfe20444ba2ef8ae93cb4866b9bc Visual C# test application source and v.8 build set. No 'funky' characters! * 3,833 16/09/2007 3b948844295efede64b94105358f2a3c Full source and build files - the whole shebang! ** 342,909 18/09/2007 c73ff479fbbfe4e341690ca657ded122

* The C# console application only contains the canned text of the original Feature Request,, and thus is VERY LIMITED in scope. But I can NOT see the 'funky characters appended to the text', so maybe this has gone away with this new TidyALT.DLL, built from CVS tidywrap and static libtidy sources of around September 13, 2007.

** WARNING: This is a FROZEN source. It is better that you download the current CVS sources, and use these to build, applying the patches given below. This source also includes the 'test' VB and C# application source, thus duplicating the above 'build set' zips. But there are no binary runtime files. Sources only.

top -|- end

Where to next? At some stage I must try to get the Visual Basic error and warning callback working, but for the moment I might try the Tidy Perl package ...


September 13-20, 2007.

diff files

MSVC8: The following diff files were made against the respective CVS sources circa 13 September, 2007

tidyatl.diff.txt - This effects the following files :-

StdAfx.cpp - Here I added a #pragma warning(disable:4996) to remove some pesky MSVC8 warnings about 'obsolete' functions.
Tidy.cpp - Since I switched the default compile to __stdcall (/Gz) I had to add __cdecl to main() to remove a warning.
Tidy.def - Only removed the ordinal numbers, since MSVC8 warned that such ordinal numbers should not be given.
Tidy.rc - Since the IDL ouput had changed from TidyATL.IDL to TidyCOM.IDL, then this is reflected in this file.
TidyDocument.cpp - This had a number of cast problems, when in UNICODE, converting it to chars to pass to Tidy, and adding a TidyBuffer initialization.

tidycom.diff.txt - This is only the commenting out of the two(2) asserts in tidylib.c. As indicated this should not be necessary, and only effects the Debug configuration anyway, since most compiles compile asserts to nothing in Release configuration.

top -|- end

 MSVC6: As a further experiment, I commenced compiling the original CVS source with MSVC6, and the test Visual Basic application with MSVB6, in a separate XP machine, but found that many of the SAME changes had to be made, and some new, different ones, especially some file name changes of build generated files - very puzzling ;=((

atl2diff6.txt - This file contains ALL the changes made to the original CVS tidyatl source - both for the TidyATL.DLL, and for the testTidyCOM Visual Basic test application - to build the sources in MSVC6 and MSVB6 respectively. The DSW/DSP build files reflect my relative folder structure. But while I was eventually able to compile a MSVC6 TidyATL.DLL, and install it, testTidyCOM consistently CRASHED!

Note the crash appears to be in the MSVC6 TidyATL.DLL, and this was despite also compiling the MSVC6 code with __stdcall, which had removed the crash in MSVC8 ...

V6 Error 1

As before, the dialog offers to DEBUG the process, but when I clicked on [Debug] I get another dialog ...

V6 Error 3


V6 Error 2

And clicking the enticing [ Yes ] opened MSVC but with a small dialog saying it can not 'run the process' - BAH!

It should be NOTED that this MSVB6 testTidyCOM.exe application ran fine using my MSVC8 compiled and installed TidyATL.DLL??? Of course this really just adds to the confusion ;=))

top -|- end

EOF - Wrap-[01-03].doc

in page links: top prerequisite building fix-ups testing error trail success callback configurations proof downloads diff MSVC6

checked by tidy  Valid HTML 4.01 Transitional