[delphizip] Re: Windows 95 Compatibility (2 new fixes!)

  • From: Daniel Marschall <uni@xxxxxxxxxxxxxxxxxxx>
  • To: delphizip@xxxxxxxxxxxxx
  • Date: Mon, 27 Sep 2010 01:28:08 +0200

With ZipSniffer I could find the 3rd incompatibility bug in a very easy way. At 
"virtual files" like "Imagestream (0)" Win95 enforces 6.3 names, which cannot 
be solved after the DLL got them, since they are not existing.

Actually, this imcompatibility of Demo 7 can be also tested under WinXP (I did 
that). I just need to set this compatibility setting.

Log of Demo 7 under XP

5> = Imagestream (0)
5> 0:Starting <unknown>
5> 0:Trace: Opening resource.zip
5> 0:Open = 0
5> 0:Trace: Closed resource.zip
5> FINISHED
6> = Imagestream (0)
6> 0:Starting <unknown>
...

Log of Demo 7 under XP with Win95 mode

7> = Images~1 (0)
7> 0:Starting <unknown>
7> 0:Trace: Opening resource.zip
7> 0:Open = 0
7> 0:Trace: Closed resource.zip
7> FINISHED
8> = Images~1 (0)
8> 0:Starting <unknown>
....
8> UNZXTRCT.CPP   636 300:Trace: starting second loop - THIS TIME we take 
action.
8> UNZXTRCT.CPP   1174 300:Trace: filnum = 0
8> UNZPROC.CPP    356 300:Trace: Done with extract/list files (error = 
357086748)
8> UNZPROC.CPP    98 300:Trace: after do_seekable, warn=0   missdir=0  missfi=0 
 losefi=1  winfi=0
8> UNZPROC.CPP    103 300:Trace: do_seekable(0) returns 28
8> UNZPROC.CPP    107 300:Trace: six
8> 0:file(s) not found
8> UNZPROC.CPP    127 300:Trace: seven
8> UNZEXEC.CPP    113 300:Trace: *** BACK FROM CALL TO process_zipfiles ***
...

I am unsure who does enforce this 6.3 thingy since the argument of DZ_Exec 
should be just some kind of DZString. Mh... maybe the "bug" which enforces the 
6.3 name is in the Delphi-part? I could imagine there is some kind of 
Filename-Extension does not care about Strings like "ImageStream (0)", but 
under Win95, the String gets handled like a filename and converted into 6.3. If 
this issue gets solved too, all functionalities of the DLL will be Win95 
compatible. I will search for the reason later.

Regards
Daniel Marschall

On Mon, 27 Sep 2010 06:15:56 +1000, R Peters <rpeters@xxxxxxxxxxxxx> wrote:
> It could be a version of the dll that will support all versions of windows
> but for the most part I prefer to distribute the dll compiled with more
> modern compiler because many bugs/security risks have been fixed.
> Looking at those changes I can see that I can adapt them into the special
> units in the 'cows' folder - these units were derived from libunicows
> which
> was a public replacement of the unicows dll (which cannot be used under
> our
> license).
> I should also be able to throw ielementary utf8 <-> utf16 conversions in
> there too.
> For the most part that code is not used on xp or later (the dll can be
> compiled without any of that code to only run on xp or above although that
> only results in a slight size improvement).
>
> For the Delphi side a UTF8 library (TNT or hacked Jedi utf8) could be
> used.
> Russell Peters
>
> On Mon, Sep 27, 2010 at 5:58 AM, Daniel Marschall
> <uni@xxxxxxxxxxxxxxxxxxx>wrote:
>
>> Ok, I will try to look at ZipSniffer and hope I can trace the
>> incompatibility in Win95. I am happy that I could help to increase the
>> compatibility for DelphiZip now for the most parts (zipping, unzipping
> etc).
>> I do not think a "special" Win95 build of the DLL is necessary. It would
> be
>> great if the handling of ZIP files for Win95 and Win7 could be done with
> ONE
>> single DLL (also since I want that my programs work on all OS without
>> changing between DLLs!) For my own SFX-Maker I use the DLL as resource
>> inside the Stub and the Stub itself is UPX packet. Since WinRAR can only
>> detect the attached ZIP, if Stub is smaller than 500 KB I have to fight
>> against the size (since VCL includes so much garbage). A second DLL for
>> older versions would be not includeable in max. 500 KB Stub.
>>
>> Anyway, you will notice that my changes in the DLL I have uploaded are
> only
>> failsafe code. They WILL NOT change the behavior of your DLL if it is
> run on
>> newer Windows versions. The only thing is that you have to use older
>> compilers (I think even the freeware Turbo C++ 2006 would do it), but
> that
>> should not conflict with any Win7 compatibilities)
>>
>> Regards
>> Daniel Marschall
>>
>> On Mon, 27 Sep 2010 05:44:09 +1000, R Peters <rpeters@xxxxxxxxxxxxx>
>> wrote:
>> > This list does not support attachments would you please send them to
>> > rpeters@xxxxxxxxxxxxxx
>> > For most of the dll changes it would be best to especially compile it
> for
>> > 95
>> > - this would also allow including utf8 support.
>> > The SFX is not handled by the dll at all (except in the case of large
> sfx
>> > command strings which presently require the dll to compress when they
>> > prepared).
>> >
>> > In the 'tools' section of the web site there is a tool called
> ZipSniffer,
>> > if
>> > it will compile and run on 95 it can be used to watch the various
>> callback
>> > events and if Trace & Verbose are set (ZipSniffer can set them) it
> will
>> > show
>> > the various diagnostic (Trace) messages including source file and line
> -
>> > this may help locating where problem is with dll operation.
>> > Note that ZipSniffer must be running before starting Zip or Unzip
>> > operation.
>> > Blast! just remembered that ZipSniffer requires utf8 support in Delphi
>> and
>> > that too will be missing but could be added.
>> >
>> > I will download your changes (from later email) and have a look at
> them
>> > but
>> > I have many time constraints.
>> > With ZipMaster I am working on moving the dll to native Delphi but
> that
>> > will
>> > take a few more versions yet.
>> > For the next version (1.9.1.x) I need to :-
>> >   1. improve utf8/utf16 support for international paths for pre D2009
>> >   2. improve error reporting to give more control over what
>> > errors/warnings
>> > are reported (also looking at extended error code giving unit and line
>> > generating the error).
>> >   3. better 'locking' of properties during operation.
>> >   4. better memory use when not busy.
>> > After that version I will move extract from the dll and then the big
> one
>> > which is moving add to Delphi.
>> >
>> > Any help is appreciated especially in catching my many initial bugs
> and
>> > testing (oh so much testing, for which there are far too many options
> and
>> > combinations to test).
>> > Russell Peters
>> >
>> > On Mon, Sep 27, 2010 at 5:02 AM, Daniel Marschall
>> > <uni@xxxxxxxxxxxxxxxxxxx>wrote:
>> >
>> >> Hello,
>> >> I was offline this night, but I have now correctly implemented and
>> > verified
>> >> the Win95 compatibility of your DLL code. Even if Win95 does not
> support
>> >> UTF8 natively, it would be still great that V1.90 works with it. And
> in
>> >> case, it is possible now, since I found nearly all incompatibilities.
> I
>> > am
>> >> very happy about this.
>> >>
>> >> Attached you'll find my final code as compatibility patch for
>> >> your DLL.
>> >> - Win95Compat.cpp
>> >> - Win95Compat.h
>> >>
>> >> All patches to make DelphiZIP Win95 compatible
>> >> - (DLL) Needs to get compiled in CB4, CB6 or similar
>> >> - (DLL) There are 4 occourences of NextChar() which have to be
> changed
>> > to
>> >> NextCharCompat().
>> >> - (DLL) There are 6 occourences of WC_NO_BEST_FIT_CHARS for the
> function
>> >> WideCharToMultiByte(). Please replace the function with
>> >> WideCharToMultiByteOptionalFlags(), so that WC_NO_BEST_FIT_CHARS gets
>> >> dropped when executing under Win95.
>> >> - (DelphiZIP) 2 DrawTextW() fixes from my initial mail.
>> >> - (DLL) Currently unknown patch to the DLL to make ImageStream demo
> work
>> >>
>> >> I have now compiled the DLL in Win95 under BCB4 and can run DelphiZIP
> in
>> >> Windows 95, 2000 and XP without problems. Great :D
>> >>
>> >> Now, the biggest part of DelphiZip is Win95 compatible. Zipping and
>> >> unzipping, even with passwords works. I also tested ALL demos which
> were
>> >> included.
>> >>
>> >>
>> >> Alas, 2 last things are still not compatible yet:
>> >>
>> >> 1. The SFX of DelphiZIP is not Win95 compatible. All labels are
>> > invisible
>> >> and errormessages (without readable content) appearing.
>> >> 2. The ImageStream demo does not work (This is the onliest demo which
>> > fails
>> >> - only on Win95). I traced it until the DLL. So, the reason is inside
>> > the
>> >> DLL. The line
>> >>
>> >> SuccessCnt := _DLL_Exec(self, CmdRecP, fDLLOperKey);
>> >>
>> >> in ExtExtract() of ZMDllOpr19.pas returns 0. This will be extremely
> hard
>> > to
>> >> find the incompatibility inside the DLL since I do not have any
>> > exception or
>> >> hint where the failure lies.
>> >>
>> >>
>> >> Well... about point (1): Alas, I cannot do that. I would die if I
> need
>> > to
>> >> update a NoVCL code ;-) Also, the SFX itself is not so necessary,
> since
>> >> people can write their own SFX, like I did.
>> >>
>> >> About point (2): This point is important to me, since it is probably
> the
>> >> last incompatibility which exists in the DLL. After that we can call
>> >> DelphiZip "Win95 compatible" (except SFX). :-) I will look if I find
> out
>> > any
>> >> information, but I fear that will be too complex for me since I have
> no
>> > clue
>> >> where the DLL behaves different in W95 than on W2K. Maybe you have an
>> > idea
>> >> what could go wrong with Stream processing at DLL.
>> >>
>> >> PS: I have not yet understood how your Verbose/Notify code in the DLL
>> >> works. I had to debug via MessageBoxA()... Is there a possibility to
>> > "look
>> >> inside" the DLL while Delphi is debugging? I really need more
> debugger
>> >> information to find the third Win95 incompatibility bug.
>> >>
>> >>
>> >> Regards
>> >> Daniel Marschall
>> >>
>> >>
>> >> -- Binary/unsupported file stripped by Ecartis --
>> >> -- Type: application/octet-stream
>> >> -- File: Win95Compat.cpp
>> >>
>> >>
>> >> -- Binary/unsupported file stripped by Ecartis --
>> >> -- Type: application/octet-stream
>> >> -- File: Win95Compat.h
>> >>
>> >>
>> >> -----------
>> >> To unsubscribe from this list, send an empty e-mail
>> >> message to:
>> >>  delphizip-request@xxxxxxxxxxxxx
>> >> and put the word unsubscribe in the subject.
>> >>
>> >
>> >
>> > -----------
>> > To unsubscribe from this list, send an empty e-mail
>> > message to:
>> >   delphizip-request@xxxxxxxxxxxxx
>> > and put the word unsubscribe in the subject.
>>
>> -----------
>> To unsubscribe from this list, send an empty e-mail
>> message to:
>>  delphizip-request@xxxxxxxxxxxxx
>> and put the word unsubscribe in the subject.
>>
>
>
> -----------
> To unsubscribe from this list, send an empty e-mail
> message to:
>   delphizip-request@xxxxxxxxxxxxx
> and put the word unsubscribe in the subject.

-----------
To unsubscribe from this list, send an empty e-mail 
message to:
  delphizip-request@xxxxxxxxxxxxx 
and put the word unsubscribe in the subject.

Other related posts: