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.
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).
For the user there isn't much changed, though I've fixed all possible memory leaks.
You should do much harm to try to get one..!
From this release on, I think it finally realy is multi-threaded.
The application will use any file at shared level, which will prevent any process to open a file for writing
if that file already is open for reading/writing. Any file that already was opened for reading are allowed to be opened
again by other processes for reading only (writing will cause an error).
This allowes you to use the application in as many processes at the same time.
Whenever you accidently enters the same output filenames, the application for that specific process will
be cleanely terminated with an error, keeping all other instances to continue their run.
Whenever an error occurs (most chance for this is during scanning of the input-files, or writing to the output-files),
originally memory leaks would have been generated (this was also the case in the original VCDxBuild),
lkVCDxBuild would exit keeping all open files opened.
In this release, whenever an error occures, first all memory will be released and any open file will be closed before terminating
the application.
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.
No major changes are in this release for the user, the big changes are 'abstract' meaning
I've removed as many possible single threaded code.
The major change will be noticeble in the equivalent of lkVCDxBuild, in the lkVCDimager-library,
which will be more multi-threaded by now...
Major change though, is that starting from this version no memory leaks will be made if an
error would occure. The internal library's are multi-threaded so you can run multiple
instances of lkVCDxBuild without a problem.
Only be sure you're not writing to the same file at once, while this would still create memory leaks.
After I've released the first version, it seemed there were too many memory leaks left,
each time an error would occure. This is solved in this second release.
It seemed that whenever a custom directory was added, that is of the (S)VCD specification,
the ISO or the OS truncates long filenames to the maximum of 15chars.
To solve this problem for once and always I've added an extra
filter so such directories will be verified according the ISO9660-1 specifications, meaning
max 8chars for the filename, 1 dot and 3chars for the extension.
If a dir-/filename is added in such a directory and its name is in lowercase, lkVCDxBuild will automaticly convert it to uppercase.
For a list of such reserved directories, click here.
After testings (in Windows and at a standalone DVD-player) it seemed that this works perfectly.
I've also added a more 'robust' filter checking for both ISO9660-1 and ISO9660-2,
so whenever a file/dir is entered that isn't correct according the specification,
lkVCDxBuild will give you more informational messages, so you know what is wrong about it.
lkVCDxBuild is a frontend using XML in order to create (S)VCD's for cue/bin, toc/img or nrg
cd-images.
lkVCDxBuild is a _forked_ version of the original VCDxBuild by Herbert Valerio Riedel.
Although VCDxBuild suited me fine, I wrote all my (S)VCD's using this frontend via a GUI (VCDwizard, another project of me),
I still was missing something. Because I wrote so many CD's, I can't figure out no more which movies/series I've got and which I don't.
To do some catologizing, I needed to add some (custom) files to the ISO-track. In this VCDxBuild is kinda limited, while it
only supports the ISO9660-1 specification in which files are written like in the "pre-historic" DOS way.
For all files which were stored using long filenames, I had to put them into a ZIP with a short filename so I could preserve the original filenames.
Although it seems for (S)VCD, the ISO9660-1 is thé specification to use for the (S)VCD specification, I was wondering why I couldn't "rewrite"
VCDxBuild so it accepts ISO9660-2.
While I was analizing the original sources of VCDxBuild, it seemed that there realy is space left in the TOC of the cd-image which VCDxBuild generates.
So I did the necessary modifications to allow longer filenames.
Naturally, the sources of VCDxBuild were written in C and _not_ win32-compliant, which forced me to realy rewrite almost everything.
At the end, the user won't see much changes (accept lkVCDxBuild allows ISO9660-2 and uses a different style of parameter processing), but internally
there are lots of changings done.
Because I prefer C++ above C, I rewrote most things into C++ (where possible though) and
which were allowed so, I optimized most by rewriting them into classes (throwing away those ancient structural programming).
Using those classes and using the MFC (Microsoft Foundation Classes), I had much more possibilities to do some things.
Some things are even changed in that way so the result will eventually run faster.
I already had communicated much with HvR about the memory leaks VCDxBuild creates, even if it finished successfully.
It took me a long time to figure out where they all were created, but eventually I managed to solve it so _no_ memory leaks will
be created after successfull installation.
One bug left over : it seems that the program will 'crash' as soon one try's to write to the same files at the same time.
Although lkVCDxBuild and all used (static) libraries are linked using the multithreaded libraries of MFC, this file-problem
would cause the program not to be allowed to run in multithreaded modus... I still had to figure out this *bug*.
Btw. This bug is also in VCDxBuild, so it's not something that is there because of me.
Most win32 users even won't see these kind of bugs in the original VCDxBuild, while the original VCDxBuild only can run
in win32 using the runtime library of CygWin (<cygwin1.dll>).
CygWin is SingleThreaded, you cannot run 2 processes of VCDxBuild (or any of the original VCDimager frontends) at the same time.