Accedi per seguire   
Seguaci 0
ZipGenius

The Truth Behind Zg 6.3 Delay

1 messaggio in questa discussione

You followers of ZipGenius activity through WinInizio.it Forum, Twitter and Facebook page, all were expecting the release of ZipGenius 6.3 that didn't happen.

We have a very valid reason.

Windows 7 is among us and we would love to release a full-featured ZipGenius release that could take benefits from the new Windows 7 features, like progress indicators in the taskbar and so on, but we would love also to revamp the code of ZipGenius in order to make it faster, better and more logical.

That's why, when we finalized ZipGenius 6.3 some week ago, we tried to perform a "jump".

ZipGenius 6.3 was compiled with Delphi 2006 (BDS) on Windows XP SP2, where we had a very stable framework and all components were working for sure; then we imported ZipGenius 6.3 code to Delphi 2010 and it was like jumping in the dark: suddenly the whole code became Unicode-compliant through a clever trick written by Embarcadero (current Delphi producer) developers, who translated non-Unicode types like "string" into an alias for Unicode supporting types. That's a great enhancement! But... Not each piece of code accepted this change :) That is specially true for old components that made their way in ZipGenius skeleton. "No problem" we thought, "we just need to go out to the Internet and search for the Delphi 2010 versions of those components"...

OH MY GOD!!! Many of those components are not updated yet or - worse - they WILL NOT BE updated by their respective developers...

Just to let you know all, here is a detailed list of "dead" components, along with their role in ZipGenius:

  • TBX Lib: compiled fine until Delphi 2009 but not developed since 2006. It was used for many buttons and toolbars in the application and, first of all, for the status bar of ZipGenius. We reaplced all TBX components with the better SpTBX Lib.
  • TISOLib: compiled fine until Delphi 2009 but abandoned in 2008. It was used to read ISO disk images.
  • RTdun_RAR3: abandoned in 2005 and the original developer released the source code that allowed us to maintain it until now. In Delphi 2010 has a strange behaviour. USED TO READ AND DECOMPRESS RAR-like ARCHIVES! Luckily we found a replacement.
  • RTdun_ACEv2: abandoned in 2005 and the original developer released the source code that allowed us to maintain it until now. In Delphi 2010 has a strange behaviour. USED TO READ AND DECOMPRESS ACE-like ARCHIVES! Luckily we found a replacement.
  • ARJUnit: never officially supported, open source unit for Delphi that allowed to read and decompress ARJ archives. It doesn't compile in Delphi 2010.
  • TVirtualExplorerTreeListView (... what a name!): used for picture preview mode, abandoned in 2008, compiled until delphi 2007, replace by TEasyListView suite from MustangPeak. Luckily, it compiles in Delphi 2010 and it is actively supported.
  • TAbbrevia: compression suite for TAR, TAR.GZ and TAR.Z archives, abandoned in 2007 but source code has been opened and someone has ported it to Delphi 2009. It runs fine in Delphi 2010.

But the worst hit we got came from the C.A.K.E. components suite, developed by my friend Joseph Leung, author of QuickZip. If ZipForge is devoted to handle the zip-like archives and it is the 50% of the whole program, CAKE represented the 30% of ZipGenius because it was devoted to handle many archive formats like CAB, ARC, ZOO, RPM, YZ1, SQX and so on.

CAKE code has been severly hit by the D2010 enhancements and it didn't compile. We looked up for errors in that code and find that we had to translate back string and char types to AnsiString and AnsiChar (sorry for technical language), which should ensure compatibility for non-Unicode source code. After that, CAKE compiled in D2010 and it has been reinstalled, but... It can't produce the files list from archives.

Actually we are in talks with Leung, who gave us a bad news: it moved away from Delphi and it is focusing on .NET development. In fact, he released CAKE 3 as a .NET assembly.

We will work with him to rebuild CAKE from the ground up for Delphi but ZipGenius development can't wait for that. So, CAKE has been pulled off from ZipGenius skeleton.

Nothing is lost, anyway.

The solutions was right in front of our eyes but we were not seeing it.

ZipGenius makes an heavy use of google.jpghttp://www.google.it/search?q=Delphi' Jedi"Delphi Jedi libraries (JCL and JVCL) for many different features of the program.

This is a great set of true open source code that everybody could use or contribute, which offers solutions for almost every task you want to fulfill with your Delphi application.

We didn't know that the JCL Library offers a JclCompression unit, which can handle almost all of the archive types already supported by ZipGenius, but also those types that we were not supporting.

That's great and that's why we delayed ZipGenius 6.3: we were trying to rebuild it on Delphi 2010 with all those new features and components, but the JclCompression unit is hour-by-hour discover and we have a lot of code to write.

So this is the plan, now:

  1. Later today we will release the ZipGenius 6.3 we compiled on XP with Delphi 2006;
  2. we will go on with the development on Delphi 2010 and we will jump a release;
  3. when we will finalize this source code trunk, we will release ZipGenius 6.5

(and we will get closer to ZipGenius 7).

Condividi questo messaggio


Link di questo messaggio
Condividi su altri siti
Accedi per seguire   
Seguaci 0