I've implemented ASPI, which allows one to use direct CDR access.
Thanks to ASPI, the addition of lkVCDxRip becomes very interesting while now one can rip a (S)VCD using the conventional way,
via a cd-image (BIN and/or NRG) but also directly from CD-Rom.
In the original VCDxRip by HvR, this was only possible when using the linux-build.
Michael Tam, author of GNU VCDImager Tools GUI for Win32,
informed me that lkVCDxBuild didn't allow one to use unreferenced Selectlist-Items.
This has been solved.
Many "helper"-routines are added, for more information goto the usage-page.
The calling method for all exported functions has been changed to WINAPI (= __stdcall FAR PASCAL), which makes it possible for developpers
of no-C++ platforms to import the functions too.
Though the method to import these functions into C++ has changed too (and made more complicated). For those,
I would suggest to download the sources of VCDwizard 2.7.0.0, in which I've implemented these changes.
Despite my effort to get the lkVCDimager-Tools to be multi-threaded, it seems libxml2 isn't that multi-threaded as it claims to be.
In fact, linking the libxml2 in win32 multi-threaded modus doesn't give much problems but when the library is realy used in multi-threading
it seems to give lots of errors. That's why I reset libxml2 to be non-multi-threaded.
In win32 this wouldn't give much trouble, while multiple processes of lkVCDxBuild runs in their own memory-space,
so each process runs its own libxml2, so eventually it will look like if it _is_ multi-threaded.
But helas, libxml2 is a bit too buggy to my requirements - so it is possible I would step from libxml2 to msxml in the future (got to figure that one out yet).
I've fixed all possible bugs I encountered while I was testing this latest release in the latest
release of VCDwizard rel. 2.6.0.0, which I updated at the same time.
Only now I can tell that this release makes me happy : it realy is multi-threaded,
whenever a process tries to open a file which already is in use by the library, the OS will prevent this
while the library will now open them using shared levels.
Files which are open for reading can be opened for reading by other processes too, but not for writing until the process
which had opened it with the exclusively shared attribute closes it.
It seemed that whenever an error occures in the library (which leads the function to terminate itself),
any opened file remained open until the calling application would close.
This seems to be the case with the original VCDxBuild too, but because that's a single-threaded console application
it doesn't do any harm : VCDxBuild would terminate so any open files are closed automaticly.
This is not the case with libraries, aspecially when they are multi-threaded.
I've fixed this. From now on, at any error during scanning and/or writing, first all memory will be
de-allocated and all open files will be closed before exiting the function lkVCDxBuild, resulting
in a clean library.
While in the past one still could have ASSERTION-messages with the released version of the library,
from this release on that will never occur again. Assertions are things for debuging, so they won't occur anymore
in the <public> release of the library.
Changed :
The function has been changed. Not 3 parameters are entered but 4 parameters,
see also Usage of lkVCDimager.
From this release on, one have the possibility to safely interrupt lkVCDxBuild during a long
operation, like during scanning of the MPeG's or during writing of the images.
The 4th parameter is a pointer to a 32-bit unsigned boolean which should be initially set to FALSE by the calling application.
Whenever this parameter comes to TRUE, lkVCDxBuild will act as if an error would have occured.
I actually don't know if there is another way to cancel a routine in a library safely,
unless one should kill the PID in the taskmanager of Windows, but that will lead to memory leaks as well..!
Just terminating the calling application won't cancel the library too, it just continues until the function is finished.
If you, a developper which uses the lkVCDimager library, don't want to take the advantage of this 'cancel'-option,
all you have to do is enter this parameter as a NULL-variable, or use the syntax for the earlier
versions of lkVCDimager.
It seems that at some win32-platforms, the program won't run without the runtime-library MSVCP60.DLL.
This was notified to me by Michael Tam, author of
GNU VCDImager Tools GUI for Win32.
From this release on, all distribution packages will have this library too.
Best location to install this library is in the SYSTEM32 folder for WindowsNT, or the SYSTEM folder for Windows9x.
If you already see such a file in the previous mentioned location, leave it and don't install the "MSVCP60"-library.
This release has some major code updates, which makes the library nearly multi-threaded.
It still will give problems when calling the library from the same process at the same time
(while there will be messages mixed up, which are send to the same window-id) but it
shouldn't be any problem anymore when the library is called in diverse processes of an
application, for instance - if you're using lkTest (the tester which comes with this
package) you won't be able to run two instances of the library within the same lkTest-window
but it shouldn't be a problem when you ran two instances or more of lkTest - just be sure
you're not writing to the same file at once while this still can give unpredictable results.
Fix Me :
I still must figure out a resolution for the file issue - the problem is that file
operations are done at low-level, so I don't know whether a file is given that should been
overwritten or it was given by mistake. Somehow I haven't figured out how I can open a file
(for writing) in exclusive mode, so other processes won't be able to write at the same time
to a file.
lkTest has had also some bug-fixes.
Actually, one could use lkTest directly as frontend/GUI if one have created a XML already.
(I do so, until I've modified VCDwizard to work with this library :
I precreate the XML in the current version of VCDwizard, does the necessary
modifications for ISO9660-2, and create the final vcd via lkTest).
Again, I've modified the libxml2 a bit so it will run in threaded model (though, I hope it
does while I just changed some internal properties of the libxml2-library) and I modified
a global parserContext structure so it will be able to carry around with my own userdata
which allows me to transfer a ptr to a dynamic created class to static functions, as
for example the logging-engine of libxml2.
I also changed the logging-engine of libvcd, so it's no longer a static function that is
called many times but just a class, that's actually pointing to the VCDxBuilder class (which
is derived from the vcd-logging class) so multi calls to the library wouldn't be mixing
up with HWND, and msgID handles nor would be the output.
In fact, where in the past the libvcd-loggingengine would be overwritten by a user-defined
loggingfunction, I've made it a virtual function so you only need to derive a new class
of the VCDxBuild class and just overwrite all virtual's which you want to act using your
code (no more statics - I hate those statics).
Even the former functions which were used to send process-information to the log-output are
now also virtual's.
In the past, the file videocd_dtd.inc,
which was compiled using the <videocd.dtd>-file, generated a large string as a global static string.
Again for optimalisation and to prevent this string gets around in the heap at every call
of the function, I've changed it so it will be a function, exporting a CString so it's
only temporarly loaded in memory when it's needed (and that is only once, when the libxml
library is initialized) afterwards it will be removed from memory.
What was in the past a bunch of static variables and static functions, I've replaced all
the former contents of the vcd_xml_dtd.* into 1 major class.
It's a ptr of this class that will be send as user_data in the xmlParserCtx when initializing
libxml2. So the calling functions (which still is a static, but inside a class) can
refer to this class.
I know - it all sounds complicated, but I sugest you checkout the code to see what I mean.
I've added all sources onto CVS, so you can browse each source-file seperately without
having to download the whole source-zip (altough I advise you to download the source-zip,
while it's always the latest 'snap-shot' of the sources, but also because I cannot add binaries to
the CVS while it corrupts them).
Although I've written a workable DLL, it seems it worked fine in lkTest, an application
I wrote to test this library. As long no errors occures, no memory leaks will occur.
As long not to the same file will be written in seperate processes, everything would be fine...
For more information about this release, I would suggest you to read the release information of
lkVCDxBuild 2.0.7.10.
Although the original VCDxBuild works fine in VCDwizard, I hated the way I had to launch it.
VCDxBuild is single threaded and console based (typical for Unix/linux applications).
I like working using the mouse, for what purpose does I have such a thing?
That's why I was very much trying to figure out ways to have VCDxBuild in somekind of a library.
After I've rewritten all sources of VCDxBuild to lkVCDxBuild,
I had to continue writing by integrating lkVCDxBuild into a win32 dynamic library.
Finally I've done it, resulting to this result.
Although this first release already works, I still have the same limitations and bugs as in the first release of
lkVCDxBuild, which I have to solve...