[delphizip] Re: DLL-Dependency and Empty message dialogs on Windows95 (Bugfix)
- From: James Turner <james.d.h.turner@xxxxxxxxxxxx>
- To: delphizip@xxxxxxxxxxxxx
- Date: Thu, 23 Sep 2010 12:40:27 +0100
Win95 compatibility in this case is not due to compiler optimization,
it's smart-linking...
Only functions that are required are linked - that includes Windows
functions. However, it's worth noting that all virtual methods of any
class that's referenced will be linked - this leads to code-bloat but
nobody has ever bothered to fix this on account of it being slightly tricky.
If anyone wishes to test software under Win95, virtualization is more or
less mandatory since no copy of Win95 will recognise new hardware. Speed
compatibility issues are only likely with specific pieces of software
rather than the OS itself. I am aware of people who still run Windows
3.1 without difficulty.
I use the following method to implement dynamic linking and maintain
backward compatibility with older operating systems...
var OpenThemeData_, CloseThemeData_ : pointer;
function OpenThemeData(WND:HWND; pszClassList:pWideChar):HTHEME; stdcall;
asm
mov eax, OpenThemeData_; cmp eax,0; je @ERROR;
pop ebp;
jmp eax;
@ERROR: mov eax, 0;
end;
function CloseThemeData(HTHEME:HTHEME):HRESULT; stdcall;
asm
mov eax, CloseThemeData_; cmp eax,0; je @ERROR;
pop ebp;
jmp eax;
@ERROR: mov eax, E_NOTIMPL;
end;
OpenThemeData_ and CloseThemeData_ are initialized by calling
GetProcAddress. Obviously, this code will need to be changed if a 64bit
compiler ever emerges (but it should trigger a compiler error rather
than crashing).
I can also provide code to check authenticode signatures on sfx archives
- it's fairly straight forward. I think it's fair to say that such a
signature should never be considered as garbage.
-- James Turner
Patrick Kolla wrote:
>>> confused. I COULD run my Delphi 2006 compilated application on Windows 95
>>> (b) without problems. But in Windows.pas it seems that GradientFill() is
>>> hard-linked (like everything). I wonder why my application is able run then
>>> :-?
>>>
>>>
>> Wow, seems that I have learned something new. My Delphi 2006 application has
>> msimg32.dll not included. Maybe the linker has not included the import
>> section because this function was never used by any component/VCL I was
>> using? So, I had luck that I used/needed only those VCLs which do not force
>> the compiler to let msimg32.dll with incompatible GradientFill() hardlink.
>>
> While the code includes a hard link, I think the compiler optimization
> removes it if it is not used in code actually compiled into the project.
> I had applications as well that would run under Win95 - that made it
> especially difficult to track, since at first I didn't suspect the
> RTL/VCL, which is part of everything.
> And sorry for the source confusion - I thought that Turbo Delphi didn't
> have it, but it seems I remembered trials which don't have it.
>
> I'm getting off topic though... just wanted to mention that it's hard to
> be Win95-compat. with Delphi 2006 (if not for GradientFill, then because
> of MsgWaitForMultipleObjectsEx).
>
>
> -----------
> 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:
