DOS ain't dead

> Changes in 3.06 (04 Sep 2010):
> * win32/pe: TLS callback support contributed by Stefan Widmann. Thanks!
> * bug fixes

> Changes in 3.05 (27 Apr 2010):
> * i386-linux and amd64-linux support shared libraries (DT_INIT must
> exist, all info needed by runtime loader must be first in .text, etc.)
> * Linux /proc/self/exe now is preserved by default, by leaving behind
> one page. New compress-time option --unmap-all-pages is available.
> * Withdraw support for shared libraries on Darwin (Apple Mac OS X)
> because upx does not understand enough about .dylib.
> * bug fixes

Honestly, I have no idea what's the benefit of those TLS callbacks in PE files ... and whether they have an impact on usability with HX

Also, AFAIK UPX itself is not free from controversy either

---
This is a LOGITECH mouse driver, but some software expect here
the following string:*** This is Copyright 1983 Microsoft ***

> > Changes in 3.06 (04 Sep 2010):
> > * win32/pe: TLS callback support contributed by Stefan Widmann.
> Thanks!
> > * bug fixes
>
> > Changes in 3.05 (27 Apr 2010):
> > * i386-linux and amd64-linux support shared libraries (DT_INIT must
> > exist, all info needed by runtime loader must be first in .text,
> etc.)
> > * Linux /proc/self/exe now is preserved by default, by leaving behind
> > one page. New compress-time option --unmap-all-pages is available.
> > * Withdraw support for shared libraries on Darwin (Apple Mac OS X)
> > because upx does not understand enough about .dylib.
> > * bug fixes
>
> Honestly, I have no idea what's the benefit of those TLS callbacks in PE
> files ... and whether they have an impact on usability with HX
>
> Also, AFAIK UPX itself is not free from controversy either

supporting TLS makes chrome become compressible (but not usable )

> > > Changes in 3.06 (04 Sep 2010):
> > > * win32/pe: TLS callback support contributed by Stefan
> Widmann.
> > Thanks!
> > > * bug fixes
> >
> > > Changes in 3.05 (27 Apr 2010):
> > > * i386-linux and amd64-linux support shared libraries (DT_INIT must
> > > exist, all info needed by runtime loader must be first in .text,
> > etc.)
> > > * Linux /proc/self/exe now is preserved by default, by leaving behind
> > > one page. New compress-time option --unmap-all-pages is available.
> > > * Withdraw support for shared libraries on Darwin (Apple Mac OS X)
> > > because upx does not understand enough about .dylib.
> > > * bug fixes
> >
> > Honestly, I have no idea what's the benefit of those TLS callbacks in PE
> > files ... and whether they have an impact on usability with HX
>
> >
> > Also, AFAIK UPX itself is not free from controversy either
>
> supporting TLS makes chrome become compressible (but not usable )
actually it is usable if you don't compress chrome.exe

> Honestly, I have no idea what's the benefit of those TLS callbacks in PE
> files ... and whether they have an impact on usability with HX
TLS refs
example simple TLS

> > supporting TLS makes chrome become compressible (but not usable
> actually it is usable if you don't compress chrome.exe

Where to get this "chorome.exe" and what is it supposed to do ?

> TLS refs
> example simple TLS

Thanks ... but ...

> Attached File ( Number of downloads: 165 )
> Login or Register to download

COOL

2 questions still open:

- Why would a Win32 devel have/want to use TLS ?
- Do they break compatibility with HX ?

---
This is a LOGITECH mouse driver, but some software expect here
the following string:*** This is Copyright 1983 Microsoft ***

> - Why would a Win32 devel have/want to use TLS ?

TLS is nearly a requirement if you use threads. The concept is not unique to win32/64, *nix has it too.

All global error variables need TLS, like "errno".

Mostly to guard against cases like:

if (read(...)==-1)
printf("errno: %d",errno);

What if this code runs in a thread, and another thread changes errno between the read and the printf ? It would send you on a wild goose chase.

TLS variables provide a way to keep global variables (both runtime internal and "visible" ones like errno) like these per thread.

TLS callbacks are different. This is mainly a problem in heterogenous programs (programs in different lanugages/runtimes, but also when e.g. DLLs and .exe's in the same language are produced independantly)

Assume that I e.g. import a package in a different language/runtime A into my main program in language/runtime B, and that language has callbacks. If package B initializes a thread and calls a callback set by the mainprogram (A), and if the callback code in A accesses A's TLS errno, then everything might go BOOM, since the thread from B is not initialized by runtime A to setup A's TLS variables (like A's errno)

Here the TLS callback enter. Every runtime registers a callback to initialize/finalize threads (and their TLS variables), so that all threads are usuable in all languages. Appararently, Windows does this registering using a table in the PE format, so that even the mainthread can be initialized using TLScallbacks. From what I get from those links, malware abuses this to run code before main() to fool naieve antivirusses.

In short, any thread capable runtime will sooner or later gravitate to TLS, but non-native Windows compilers (like gcc) might not exploit all Windows features (e.g. register them via PE tables)

Thanks.

> > - Why would a Win32 devel have/want to use TLS ?

> TLS is nearly a requirement if you use threads. The concept is not unique

7-ZIP always worked for me with its threads, no TLS issues ...

> TLS callbacks are different. This is mainly a problem in heterogenous
> programs (programs in different lanugages/runtimes, but also when e.g. DLLs
> and .exe's in the same language are produced independantly)

interesting ...

> malware abuses this to run code before main() to fool naieve antivirusses.



> In short, any thread capable runtime will sooner or later gravitate to TLS,
> but non-native Windows compilers (like gcc) might not exploit all Windows
> features (e.g. register them via PE tables)

wow ...

---
This is a LOGITECH mouse driver, but some software expect here
the following string:*** This is Copyright 1983 Microsoft ***

There's 3.07 out :)
http://upx.sourceforge.net/#downloadupx

Changes in 3.07 (08 Sep 2010):
* win32/pe: fixed relocation handling for files with *no* TLS callbacks
[severe bug introduced in 3.06]

BTW I read that this TLS code can be abused by various malware because there's some extra section in PE which is executed before normal entry point is called and it's harder to debug it in common debuggers. There was also some sample code that popped a message box from this section. I don't remember where, it's some months ago...

---
DOS gives me freedom to unlimited HW access.

> 7-ZIP always worked for me with its threads, no TLS issues ...

That's probably because 7-zip's model doesn't need to be very sophisticated. Take chunk, compress, report back, that is about it.

> Changes in 3.07 (08 Sep 2010):
> * win32/pe: fixed relocation handling for files with *no* TLS callbacks
> [severe bug introduced in 3.06]

COOL. I don't have big ambitions with TLS for now but at least it seems to be still able to unpack itself and Khusraw's MPLAYER:

---
This is a LOGITECH mouse driver, but some software expect here
the following string:*** This is Copyright 1983 Microsoft ***

---
This is a LOGITECH mouse driver, but some software expect here
the following string:*** This is Copyright 1983 Microsoft ***