I don't have ATT fiber firewall in my hometown:) diligent hands rule....

I would call it: "MY OWN reference implementation". :-D "In testa che avete, Signor di Ceprano?" -- Rigoletto

OK, got it. Reminds me of the old IBM Block mode terminals that had a physical map (with all literal fields and color specs, input specs and protection specs) and a data map that was only the fields that returned values. Both were sent to the terminal which would use a forward only processing to paint the screen and enable the unprotected fields. Any action key on the terminal transmitted only the data map to the invoking program. It was up to the program to split the data map back into fields and do any validation and processing of the data. (very efficient use of transmission bandwidth in the old days.) :)

You aer welcome :) M.D.V. ;) If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about? Help me to understand what I'm saying, and I'll explain it better to you Rating helpful answers is nice, but saying thanks can be even nicer.

Thank you, your answer is helpful

Thanks for the smiley Kent, that's still a non answer though. Blink twice if you are under a NDA. I’ve given up trying to be calm. However, I am open to feeling slightly less agitated. I’m begging you for the benefit of everyone, don’t be STUPID.

Sounds like a fun project. I hope it all works out the way you want it to!

raddevus wrote: I am still very curious if a 64 bit app can eat all of the memory on a large server (64GB RAM or something larger). I'm guessing that it cannot since 1. I believe that any app cannot allocate RAM beyond its address space. If you by 'address space' refer to the entire 2**64 bytes space that a 64 bit process can cover by its addresses, 16 exbi bytes (more than 16 million gigabytes), your assumption is right: A process cannot allocate that much space. And we will never see a computer with 16 exbi bytes of RAM. Never ever. In no general machine (excluding e.g. embedded processors) of the last 30-40 years has the address indicated by the program code been used directly as the physical RAM address. The virtual address in the program is translated to a different physical address in RAM through a set of hardware translation tables, managed by the OS, called the Memory Management System (MMS). Each process has its own set of MMS tables. The OS sets up the MMS tables for a tiny slice of the virtual address space. If the program presents a virtual address within this slice, the range covered by the MMS tables for that process, it is translated to a physical RAM address. If the virtual address is outside the range covered by the MMS tables, an interrupt is generated, and the OS will terminate the process. (Well, it might offer a mechanism for reporting the interrupt e.g. to a debugger that can inspect the process state before it is cleaned out.) If you by 'its address space' refer to just that slice of the total 64 bit virtual address space for which the OS has set up translation tables, then you are essentially right. The size of this slice can be a few hundred kiB, a few GiB, or many GiB - but the OS will not give you more than it is capable of handling. When an app allocates RAM, the allocated space is, at the outset, within the address space translated by its MMS tables. If the malloc/new/... maps down to an OS request, the OS may say: 'There isn't enough unused space in the already mapped virtual address space, so I have to add another entry to the mapping tables, expanding the address space available to that process'. Before the OS does that, it will check that the process does not already control an excessive amount of address space. The limit is set by the OS to any value that it can handle. In many systems, malloc/new/... starts out as a call to a runtime library in the process address space. As long

You're right, a lot of people have no idea what they need, and that SVG isn't special in its bloat. It's just overwhelming to deal with. But I really want nice pretty vector graphics for my little ARMs and stuff, and now the 32 bit ones have enough ooomph to do it. I just got sick of interfaces that look like they were crafted in the mid 1990s. LVGL seems to find its way around that, even with raster graphics, but I couldn't make heads or tails of its rendering process. I wasn't really going to do a whole vector engine, aside from loading and rendering a reasonable SVG subset which I already had finished, but not one with an exposed API you could draw with. The reason I did is I could not find efficient algorithms for doing anti-aliased draws with alpha-blending. The anti-aliasing would cause pixels to be drawn in the same place twice, which fouls alpha-blending. With vector graphics you get the mess basically as a series of polygons except all the lines are actually bezier curves. When you go to render, the way it's done, the issue above isn't an issue. But it's sort of an all or nothing deal because the latter works nothing like the former at all. Check out my IoT graphics library here: https://honeythecodewitch.com/gfx And my IoT UI/User Experience library here: https://honeythecodewitch.com/uix

It uses some code from Freetype, and my license documentation will reflect that. I'm actually pouring over all the code to convert it to C++ and do things like integrate it such that it uses my bitmap class instead of its own - that sort of thing, so I'm pretty familiar with where the codebase comes from. And I've worked with FreeType before and am familiar with it, which is why I made TinyTTF - and contributed that to LVGL as it runs in more places. That said, the freetype bits used in pluto isn't very heavy - just typedefs and rasterization algorithms. Check out my IoT graphics library here: https://honeythecodewitch.com/gfx And my IoT UI/User Experience library here: https://honeythecodewitch.com/uix

Oh no it wasn't anything inherent to VB, writing 1000 lines undocumented functions can be done (and I saw it multiple times by so-called professionals) in any language. I worked a lot on VB6 in my first company and honestly I liked it. It lacked some features and had a few quirks but for its role it's really comfortable. It gives a lot less bad habits than its strongest current competitor, which in my opinion is Python. As a quick GUI to call library functions it's just unbeatable, but take my opinion with a massive grain of salt - if some crazy mofo in MS will ever release a VB7 I'd jump on it in .3 nanoseconds. GCS/GE d--(d) s-/+ a C+++ U+++ P-- L+@ E-- W+++ N+ o+ K- w+++ O? M-- V? PS+ PE Y+ PGP t+ 5? X R+++ tv-- b+(+++) DI+++ D++ G e++ h--- r+++ y+++*      Weapons extension: ma- k++ F+2 X The shortest horror story: On Error Resume Next

We have an inhouse debugging tool I developed that we use a lot. It's been under active development since 2000. I run into the problem you describe every couple of years. I'll have let small improvements and bug fixes accumulate, and then work on the app for a while. It's tough to finally say "enough's enough". I have occasionally let the fun of working on the thing get the best of me and then I end up with features that are... gonzo. Case in point: The app has a palette of colors the user can choose from. Instead of using any of the countless color pickers out there, the app lets you pick from an image either embedded in the app or an arbitrary image you specify. It's cute, but hardly necessary :-O. Software Zen: delete this;