Alternatives
in [Visual Basic]
|
From: Schmidt on 17 Jan 2009 09:07 "Ulrich Korndoerfer" <ulrich_wants_nospam(a)prosource.de> schrieb im Newsbeitrag news:OuuQq84dJHA.4004(a)TK2MSFTNGP05.phx.gbl... > 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 that. > 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. ;-) Olaf
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> wrote: in <OJUk8O4dJHA.5540(a)TK2MSFTNGP05.phx.gbl> >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 >> days. > >I've been *totally* avoiding the Windows Tax myself, lately! > >http://www.dell.com/business/desktops?~ck=mn#subcats=&navla=80770~0~1791343&navidc=Operating%20System&navValc=FreeDOS%20and%20Linux&a=80770~0~1791343 > >-- >.NET: It's About Trust! > http://vfred.mvps.org > 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! --- Stefan Berglund
From: Ulrich Korndoerfer on 18 Jan 2009 19:12 Hi Olaf, Schmidt schrieb: > ... >> 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: --- http://stackoverflow.com/questions/353634/are-there-any-downsides-to-using-upx-to-compress-a-windows-executable 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 memory. 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 system DLLs). --- http://www.jrsoftware.org/striprlc.php#execomp 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 EXEs.) Update: In fairness, this was written several years ago. This very well may no longer be an issue today. --- http://linux.die.net/man/1/upx NOTES FOR LINUX [general] Introduction 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 ("linux/386"). 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. --- http://dundats.mvps.org/Windows/General/DLL.HTM Features of DLL files Memory management 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. --- http://forum.xda-developers.com/showthread.php?t=271535 UPX'ed applications packed on ROM? Hi all, 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 much. Disadvantages: * longer load time because of uncompresion * more memory consumption Advantages: * 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. -- Ulrich Korndoerfer 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 news:uuBhrL4dJHA.2112(a)TK2MSFTNGP02.phx.gbl... > 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... > > http://vb.mvps.org/images/ballmerceo.gif > 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 news:OKNRBetdJHA.5344(a)TK2MSFTNGP05.phx.gbl... > > 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 Microsoft <unbelievable/> 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. |