From: Schmidt on 17 Jan 2009 09:07
"Ulrich Korndoerfer" <ulrich_wants_nospam(a)prosource.de> schrieb im
> You remember that UPXed libraries can not be shared in memory?
You told me that earlier, yes - but I was/am not really
convinced about that, since I find no appropriate Infos
in the Web which state that clearly (for Dlls).
Independent from that, the framework-dlls are not "huge" -
and they are normally deployed within the App-Path,
beside the Exe - so the only processes which could
benefit (only a little bit, because the Dlls are small)
from "sharing", would be your own App-Processes,
in case the user really starts *many* multiple Instances
of them - not really a problem IMO - would say, the
benefits from faster Load-Times (the decompression-
speed of UPX is with ca. 250MB/sec much higher than
the Disk-Read-Speed) and the somewhat smaller
deployment-size, balance that well IMO (in case it
really is as you say).
And those who want to "de-UPX" can do that at any
time - there's no password-protection or something like
> So zooming and rotating of text, before it is rendered,
> is a snap, even on complex output with embedded text.
Yep, and the nice thing about how that works is, that
these Scale- or Zoom-modes work transparently through-
out a (to be) rendered Widget-Hierachy. If I set a Scale of -
let's say - factor 2.0 only on the Root-Widget (which covers
a whole Form-Area for example), then all Child-Widgets
inherit this scalefactor automatically, without the need, to
adapt their internal Drawing-Coords explicitely - all widgets
would be rendered twice as large - and if one widget in
this hierarchy decides, to set its Scalefactor to 0.5, then
the resulting size of only that widget (and all its child-widgets)
would be back at "100%" - and that's really only one
cairo-scale-call *before* a widget starts to render itself
(can be done outside of the widgets drawing-code) - as
said, no special adaption of drawing-coord-Params is
needed in the widget(s) internal Drawing-Calls.
> So the vbWidgets engine can render in traditional
> UserControls (that then serve simply as a container
> window) placed on a traditional form.
Yep - and that works really well also with Windowless
Usercontrols - a hWnd is not really needed for a Widget
to be hosted, only a hDC, the "outer Dimensions" and
the Mouse- and KeyStreams ... and all that is available
also within windowless VB-UserControls.
> And there will be new "forms", generated by the new
> Forms-engine (which creates toplevel windows from
> scratch and handles all the necessary window subclassing)
> and the vbWidgets engine can render its controls in
> those forms too.
Yes - we will see, how this Form-Engine evolves over
time - the Form-Interfaces (Properties, Events) are
nearly 100% compatible to the VB-Forms - and on top
of that many additional things can be implemented, as
e.g. Min- and Max-Dimension Properties - watching for
special Sys-Messages (which make sense to be "raised"),
etc. pp. - but the main-purpose of these Forms is,
to deliver a 16Bit-UniCode-Keystream in the
KeyPress-Events (in a compatible Event-Declaration,
since the KeyAscii-Param already is a 16Bit-Integer)
throughout the hosted Widget-Hierarchy.
> How stable is the design of the widgets engine?
The GDI-version was already very stable - now I have
something more on to-do, since we have this nice
scaling-capabilities - and that requires some thoughts
now, how to handle and translate the MouseEvents in
the WindowManager against (independently) zoomed
Widgets in the best and cleanest way - I mean - if
we have something like that "for-free" thanks to cairo,
then this shouldn't "break" e.g. the MouseCursor- or
Caret-Positioning in a zoomed TextWidget - that's my
test-case - and my "new challenge", so to say.
> If it already makes sense at this time, you may
> (if you like) hand me over some tasks (per private mail),
Will see, that I put at least a small Demo with some
simpler Cairo-widgets together as a preview - Jeremiah
also wants to see something "working" on his new Forms.
I will send you a small package, when I'm ready with the
"basics" in the reworked, cairo-adapted WindowManager.
> at least I can do some code beautyfying :-).
Yep, that's probably necessary for most of my initial Code...
but when the project got momentum and maybe someone
defines (and also *controls* then from time to time) some
Coding-Rules for the project, I would of course try to
follow that defined style in my own commits later on. ;-)
From: Stefan Berglund on 17 Jan 2009 19:35
On Thu, 15 Jan 2009 18:40:02 -0800, "Karl E. Peterson" <karl(a)mvps.org>
>Ken Halter wrote:
>> want to go today" question, seems to be "To the nearest PC with Linux
>> installed". Several PC manufacturers are offering Linux as a choice these
>I've been *totally* avoiding the Windows Tax myself, lately!
>.NET: It's About Trust!
Yep, I'm starting a new business that runs on an Apache web server using
PHP and PostgreSQL that will be browser accessible from any platform.
It's absolutely amazing what can be done with AJAX. And some serious
CSS gives you buttons that depress that aren't really buttons at all and
draggable divs. It looks and works almost 'zactly like a desktop app
but with zero Windows Tax. :-)
Tell Ballmer the cat's out of the bag and the horse has left the barn!
From: Ulrich Korndoerfer on 18 Jan 2009 19:12
>> You remember that UPXed libraries can not be shared in memory?
> You told me that earlier, yes - but I was/am not really
> convinced about that, since I find no appropriate Infos
> in the Web which state that clearly (for Dlls).
Search phrase for Google: "upx shared dlls"
Among the first 20 results are:
There are three drawbacks:
1. The whole code will be fully uncompressed in virtual memory,
while in a regular EXE or DLL, only the code actually used is loaded in
memory. This is especially relevant if only a small portion of the code
in your EXE/DLL is used at each run.
2. If there are multiple instances of your DLL and EXE running,
their code can't be shared across the instances, so you'll be using more
3. If your EXE/DLL is already in cache, or on a very fast storage
medium, or if the CPU you're running on is slow, you will experience
reduced startup speed as decompression will still have to take place,
and you won't benefit from the reduced size. This is especially true for
an EXE that will be invoked multiple times repeatedly.
Thus the above drawbacks are more of an issue if your EXE or DLLs
contains lots of resources, but otherwise, they may not be much of a
factor in practice, given the relative size of executables and available
memory, unless you're talking of DLLs used by lots of executables (like
Why not use an EXE compressor?
Some have asked why I made StripReloc when there are EXE compression
programs such as ASPack and UPX that will trim more bytes off of
executables than StripReloc ever could.
The reason is there are downsides to using EXE compressors. Most notably:
* Upon startup of a compressed EXE/DLL, all of the code is
decompressed from the disk image into memory in one pass, which can
cause disk thrashing if the system is low on memory and is forced to
access the swap file. In contrast, with uncompressed EXE/DLLs, the OS
allocates memory for code pages on demand (i.e. when they are executed).
* Multiple instances of a compressed EXE/DLL create multiple
instances of the code in memory. If you have a compressed EXE that
contains 1 MB of code (before compression) and the user starts 5
instances of it, approximately 4 MB of memory is wasted. Likewise, if
you have a DLL that is 1 MB and it is used by 5 running applications,
approximately 4 MB of memory is wasted. With uncompressed EXE/DLLs, code
is only stored in memory once and is shared between instances.
* Some older virus scanners flag compressed EXE/DLLs as being
virus-infected. (This is this reason I stopped compressing Inno Setup's
Update: In fairness, this was written several years ago. This
very well may no longer be an issue today.
NOTES FOR LINUX [general]
Linux/386 support in UPX consists of 3 different executable formats,
one optimized for ELF excutables ("linux/elf386"), one optimized
for shell scripts ("linux/sh386"), and one generic format
We will start with a general discussion first, but please
also read the relevant docs for each of the individual formats.
Also, there is special support for bootable kernels - see the
description of the vmlinuz/386 format.
General user's overview
Running a compressed executable program trades less space on a
''permanent'' storage medium (such as a hard disk, floppy disk,
CD-ROM, flash memory, EPROM, etc.) for more space in one or more
''temporary'' storage media (such as RAM, swap space, /tmp, etc.).
Running a compressed executable also requires some additional CPU
cycles to generate the compressed executable in the first place,
and to decompress it at each invocation.
How much space is traded? It depends on the executable, but many
programs save 30% to 50% of permanent disk space. How much CPU
overhead is there? Again, it depends on the executable, but
decompression speed generally is at least many megabytes per second,
and frequently is limited by the speed of the underlying disk
or network I/O.
Depending on the statistics of usage and access, and the relative
speeds of CPU, RAM, swap space, /tmp, and filesystem storage, then
invoking and running a compressed executable can be faster than
directly running the corresponding uncompressed program.
The operating system might perfrom fewer expensive I/O operations
to invoke the compressed program. Paging to or from swap space
or /tmp might be faster than paging from the general filesystem.
''Medium-sized'' programs which access about 1/3 to 1/2 of their
stored program bytes can do particulary well with compression.
Small programs tend not to benefit as much because the absolute
savings is less. Big programs tend not to benefit proportionally
because each invocation may use only a small fraction of the program,
yet UPX decompresses the entire program before invoking it.
But in environments where disk or flash memory storage is limited,
then compression may win anyway.
Currently, executables compressed by UPX do not share RAM at runtime
in the way that executables mapped from a filesystem do. As a
result, if the same program is run simultaneously by more than one
process, then using the compressed version will require more RAM and/or
swap space. So, shell programs (bash, csh, etc.) and ''make''
might not be good candidates for compression.
Features of DLL files
In Win32, the DLL files are organized into sections. Each section has
its own set of attributes, such as being writable or read-only,
executable (for code) or non-executable (for data), and so on.
The code sections of a DLL are usually shared among all the processes
that use the DLL; that is, they occupy a single place in physical
memory, and do not take up space in the page file. If the physical
memory occupied by a code section is to be reclaimed, its contents are
discarded, and later reloaded directly from the DLL file as necessary.
In contrast to code sections, the data sections of a DLL are usually
private; that is, each process using the DLL has its own copy of all the
DLL's data. Optionally, data sections can be made shared, allowing
inter-process communication via this shared memory area. However,
because user restrictions do not apply to the use of shared DLL memory,
this creates a security hole; namely, one process can corrupt the shared
data, which will likely cause all other sharing processes to behave
undesirably. For example, a process running under a guest account can in
this way corrupt another process running under a privileged account.
This is an important reason to avoid the use of shared sections in DLLs.
When a DLL is compressed by an executable packer, such as UPX, all of
its code sections are marked as read-and-write, and therewith unshared.
Read-and-write code sections, much like private data sections, are
private to each process and backed up by the page file. Thus,
compressing DLLs increases both their memory and disk space consumption,
and should be generally avoided for shared DLLs.
UPX'ed applications packed on ROM?
I don't know if 'The Devs' already use it, but UPX
(http://upx.sourceforge.net) is free (open source) and can pack binaries
so that they take up a smaller space. they get a small overhead to
unpack, so they may end up taking a little bit more memory. But in the
case of the Blue Angel, it looks like memory is not going to be an
issue, right? even though, it looks like the memory overhead isn't that
* longer load time because of uncompresion
* more memory consumption
* Exes and DLLs take up less space
The UPX devs themselves explicitly say compressing DLL may cause way
more consumption, because less resources would be shared. compressing
exes does not look that troublesome.
If those cites aren't enough, I could dig further on to the next search
result page :-)
> Independent from that, the framework-dlls are not "huge" -
> and they are normally deployed within the App-Path,
> beside the Exe - so the only processes which could
> benefit (only a little bit, because the Dlls are small)
> from "sharing", would be your own App-Processes,
> in case the user really starts *many* multiple Instances
> of them - not really a problem IMO - would say, the
> benefits from faster Load-Times (the decompression-
> speed of UPX is with ca. 250MB/sec much higher than
> the Disk-Read-Speed) and the somewhat smaller
> deployment-size, balance that well IMO (in case it
> really is as you say).
When sending dlls over the wire for to be installed on the users system,
upxed dlls gain nothing as as well the dll could be packed into an archive.
Startup time gains are neglectable, as it doesnt really matter wether a
dll, having say 1 MByte unpacked, is loaded from a HD with 20 MB/Sec
and needs unpacked to load 1/20 sec or packed (then say having 500 kB)
is loaded and unpacked in 1/40 sec. And the ratio gets (much) worser the
bigger a dll is, because code and embedded ressources of unpacked dlls
is not loaded at once completely on startup, but the needed portions are
loaded only, where on the contrary for packed dlls every byte is loaded
to memory and decompressed.
Virus scanners tend to detect UPXed files as virus.
That the user! has the choice to unpack a dll on its own is a dubious
argument, because most users will not recognize it as packed nor are
they able to unpack. The developer using the dlls could unpack them, but
heck, what about the other way round? If a developer wants dlls to be
packed, let him pack himself.
Also (may be not mentioned in the cites from above) there may be issues
with unloading a dll after it is not longer used. There are rumors that
in certain cases a dll loaded with LoadLibrary is not unloaded by
UnloadLibrary, when UPX packed.
As a summary: packed dlls save some disk space (which is neglectable on
hd with nowadays terabytes of storage), save perhaps a little bit but
neglectable loading time, eat much more ram (which even nowadays is an
existing constraint, think of 32 Bit Windows which can access at max
about 3 GB Ram) and may trigger false virus positives.
>> If it already makes sense at this time, you may
>> (if you like) hand me over some tasks (per private mail),
> Will see, that I put at least a small Demo with some
> simpler Cairo-widgets together as a preview - Jeremiah
> also wants to see something "working" on his new Forms.
> I will send you a small package, when I'm ready with the
> "basics" in the reworked, cairo-adapted WindowManager.
Ok, waiting for it.
>> at least I can do some code beautyfying :-).
> Yep, that's probably necessary for most of my initial Code...
> but when the project got momentum and maybe someone
> defines (and also *controls* then from time to time) some
> Coding-Rules for the project, I would of course try to
> follow that defined style in my own commits later on. ;-)
Now collecting and posing coding rules is a heavy task and anyone will
disagree with the rules posed :-)
But for your coding style anything else than nothing is better (sorry
for this, I could not resist to say this :-))
Nevertheless for all participants a rudimentary set of rules could be
helpful, of course.
What I mean: your code gets much more readable if even a small set of
coding rules is applied. This small set would contain just some
generally accepted standards like eg. declare every variable using its
type name, not its type character, explicitely preceed byref method
parameters with ByRef keyword and some more :-).
Btw, there are two common tasks which could be assisted by the widget
set (probably implemented in helper classes):
A) localization of text messages
B) action state management and dispatching
As for localization I think best would be to use the concept of a
default locale, having all text strings written in this locales language.
For widgets during design time eg a caption text could be set, using the
default language. This text string would be stored in the Caption
property as usal, perhaps additionally with a hash of the string. When
the application is run (wether in debug mode in the IDE or compiled
outside the IDE), the widget on startup first determines from an
application wide object (something like the VB App object) the locale to
be used. If it is the default locale, the widget just loads the caption
string from its property store. If it is not the default locale, it
either loads the default locale string or its hash and then queries the
application wide object for a translated string, using the defalut
locale string or its hash.
For strings set programmatically during runtime, they would be loaded by
using a function of the application wide object. The function gets as
parameter the string in the default locale, and returns a string
corresponding to the locale set. If it is the default locale, it just
returns the string, otherwise it returns a translated version.
In any case, when a translated version is not available, the string in
the default locale is used.
The purpose of this is to:
- have automated locale switching
- all necessary strings are set in the program code, using the default
locale (which would be a project property). There is no need to pull
them from an external table. This is good because there is no need for
the programmer to keep track of whats in the external table. Any changes
to strings necessary is just done there where needed, in the programs code.
- translaters can get (by to be defined means) an automatically extract
of all used strings and then just one by one have to translate the strings.
Action state management and dispatching is a task that should be
assisted by the widgets too, eg. by an action object property of the
widget, that can be set to an action object.
Dispatching is the wiring of events that trigger actions to action code.
It is common that actions can be triggered from different places, eg.
from menu entries, from toolbar buttons, from keys and so on. Many
triggering events are wired to the same action code.
State management at least should allow to set an action as eg disabled
in its action object and then all GUI visible state should change
accordingly (menu item and tool button grayed, key hit not evaluated,
and so on).
And probably state transition management should be implemented. A global
state object should maintain state, diswallowing certain transitions and
allowing other transitions. An action triggered or running should change
global and local state. I hope you got the picture. This is a wide field
and not easy to implement.
VB tips, helpers, solutions -> http://www.proSource.de/Downloads/
From: "Bill McCarthy" TPASoft.com Are Identity on 18 Jan 2009 19:36
"Karl E. Peterson" <karl(a)mvps.org> wrote in message
> Bill McCarthy wrote:
>> Note MSFT dropped in 2000, and has remained pretty much flat since.
>> Absolutely no correlation to the NASDAQ or DOW etc.
> The correlation is to Ballmer's ascendency, which corresponded to the
> first previews of VB.NET at PDC...
Ballmer according to your graph took over on Jan 13, 2000. The first
previews of .Net were in June or July, as was Windows XP.
From: "Bill McCarthy" TPASoft.com Are Identity on 18 Jan 2009 19:43
"Ken Halter" <Ken_Halter(a)Use_Sparingly_Hotmail.com> wrote in message
> Holy smokes! An unbiased opinion! Say it ain't so!
"Unbiased" is when you look at the facts Ken, not when you post a link to
some software you haven't even tried and then tack on a heap of anti
Microsoft nonsense claiming the current global credit squeeze is due to
I suggest you actually look at Jabaco. You will find it is a poor VB
implementation on top of Java. There's not even a Debug.Print. form's are
missing dozens of properties and because it is based on swing, there isn't
even a form's hWnd. You cannot use API of any king, no type libraries, no
COM components. And again, because it is based on Java, you've got that
GC object model lifetime issues (lack of determinalistic finalization).
Rather than expose that, they just cut out the Terminate event entirely from
the class modules. It's totally lame.
If you want to code against Java, use Java. You'll find there's lots of
tools, support, samples etc.