Since the advent of Windows 10, Microsoft has been working hard at universalizing application install and development to what they call the Universal Windows Platform or UWP.
A large part of that universalizing task is to keep existing Win32 applications available, saleable, working as intended, and candidates for Windows store, on an expanding windows hardware platform, without a complete re-write and substantial re-invention on a new coding platform.
Win32 and Win64 have historically been aimed at the Intel-style processors that we find in our desktop computers. The windows API which underlies the Clarion language and CHT API-based extensions to Clarion native language code, traditionally have addressed only these Intel-style processors.
The idea of a "Desktop Bridge" or an "App Converter" as discussed in the linked video (below) is that Microsoft's UWP is to be processor agnostic. The Windows APIs and the DLLs in which these are embedded are evolving to other processor types which can, for example, lower energy consumption, yet operate at clock-burning cycle speeds, for insertion into smaller and portable devices.
In theory, a "bridged" app will address all UWP features and APIs across a range of processors in a far wider range of hardware plaftorms besides the ones based strictly on Intel-style processors. And with that comes immediate access to the Windows Store, and new Windows 10 features such as moveable, malleable menu "Tiles".
An example of an early implementation of UWP, is the Nokia Windows 10 Phone that I purchased in October/November of 2016.
This runs a very viable version of Windows 10 on a QaulComm SnapDragon Processor.
This Windows phone, is "kick-ass" and second to no others that we've tested from other vendors. The screen is bigger than most phones, but not still not big enough to do serious work other than sending emails and text and reading kindle books (with the text enlarged). But hooked to a keyboard and full-sized monitor via a provided interface device, it's a serious, contender with an Intel-based "desktop" computer because of its power. Best of all, it's running a familiar O/S - Microsoft Windows 10.
Microsoft has already stated its intention to further develop the small, portable device market with larger-than-phone but smaller-than-tablet devices based on SnapDragon and perhaps other new, powerful, and low-energy-consumption processors.
At the heart of their UPW strategy is helping developers of legacy Win32/Win64 apps to keep their existing code running on UWP and filling the gaping canyon of missing Windows-on-smaller-device apps with already successful Win32/Win64 applications from the Intel-processor world where they were first conceived.
CHT's "Next Generation" initiative is dedicated to getting your Clarion 10 applications running, installing and selling on the UWP.
Some background theory: (Desktop Bridge):
Any questions? Feel free to ask.
The Clarion Handy Tools Page
As of approximately 6PM EDT, September 17, 2017, we've completed posting CHT Build Update 21B.01.00.
There's no mystery to what was worked on in the intervening period from 21B.00 to this update 21B.01. If you're interested, just read fully through our April and May 2017 "What's New" pages.
With the changes accomplished for 21A.xx and 21B.00, the work was all about server efficiency, speed and flexibility.
And now, with the low-level robustness changes in the server modules, tested and discussed here over the month of April and early May, we're on a roll to launch your Clarion apps into an whole different design paradigm.
The Clarion Handy Tools Page
We've changed and optimized every one of our 22 CHT servers at least a half-dozen times over the last few weeks as we've tested and experimented with various settings.
Today, you may have been kicked off or found a particular server unavailable as we've been testing, particlarly our website site server, our forum server, and our installation download servers. We turned these off intermittently in order to replace their executables. If one of these forced terminations happened to you recently, please accept our apologies. It was in the general interest of pushing things along, rather than waiting for you to sign out.
One of the most interesting things we found, from the numerous tests performed, was discovered quite recently, in the last week or so -- interesting enough to tell you about.
Here's our finding:
We had to account in our server code for possible latency at the client end in receiving these other page components that are called for by the browser from HTML. Even though the server end may already have finished sending the files requested by the browser, there's no guarantee that, client side, the files have fully arrived and have been rendered.
So we needed to build in some stretch-time before the server closed the upload socket. We found that closing the socket too early, server-side, even though the server had finished sending, could cause the client software to prematurely stop receiving the data stream on the way to it, resulting perhaps in an incomplete .CSS control file, .JS code file, .PNG image file or data package file.
Once we realized this possibility, testing from various low-to-high quality connections, we built a mechanism into our server code that delays socket closes.
The same principle also applies with streams of data going to client servers. Though in this case there aren't as many pieces involved, as a single browse consists of one data package or data stream. A double browse, consists of two data packages or streams, and so on.
A FAST server connection such as ours is able to fill the server-side-end of the data pipe at amazingly fast rates. But, just because the server has finished filling the pipe, doesn't guarantee that the other end of the pipe, the client's end, is completely finished acquiring or processing that stream. Picture a garden hose with a swelling in the middle and a gallon of water having gone in at the faucet side and only 6 ounces of water having yet come out at the sprinkler end.
The "catch-all" term used for this imbalance of processing speed is "latency" in the connection.
A rule of thumb we've deduced from all of this, is to generally not close sockets at the server end, even though they may have completed their upload task, and to use a "soft-close" that leaves these sockets open, but off-limits to further server-side use, until the client side performs a close on them from it's end.
Browsers generally do this client-side-close once a page is fully rendered. And CHT data clients always perform a client-side-close when they've finished receiving any data package.
As mentioned above, we've experimented extensively over April and early May 2017, to the point that we're comfortable with the performance. And if settings need to be tweaked, we've provided code-hooks that make tweaking easy, fast and flexible.
As of this PM, we're getting ready to package Build 21B.01.00 and all going as planned we should be able to post it by evening tomorrow. (May 17th, 2017)
We will report here one way or the other if anything changes.
The Clarion Handy Tools Page
We've spent the last 30-40 days deep inside a few of our server and client modules making modifications and improvements spun off and tested resulting from the "stress" tests that we performed and posted about on our forum and on our April 2017 "What's New" pages.
As a result of that work, the abiltiy of our servers to receive LARGE files, or data streams, and return LARGE files or data streams has been changed.
Prior to this work the largest file or data entity accepted for UP-POSTING and DOWN-POSTING in a single transaction, was approximately 300MB.
This limit has essentially been lifted altogether. So there's no theoretical size limit.
We have set an arbitrary size limit of about 1.5 GIG by way of two equates called
HPROP:MaxUploadPutFileSecure, but these are purely
arbitrary on our part.
They're, just a way for you/us to maintain control over the size of files and data going UP and DOWN. These two values can be simply adjusted in the HNDEQUSK.CLW equates file to suit your/our own preferences.
The modules worked on during these last 30-40 days include:
The spirit of these modifications has to do with providing a wider variety of formalized HTTP pathways to obtaining data FROM a CHT server and posting data TO a CHT server.
As far as we're concerned HTTP might as well stand for (H)andy (T)ools (T)ransfer (P)rotocol instead of its original meaning: (H)yper (T)ext (T)ransfer (P)rotocol.
HTTP protocol was originally released in 1989/90. We began using it as the default data-transfer protocol in our CHT data servers approximately in 2003.
The entire world wide web system depends and operates on HTTP, which is defined as both a "Connectionless" and "Stateless" protocol. This means that HTTP does not rely (necessarily) on a persistent connection the way that, say, network protocol does. A socket connection lasts as long as it takes to make a request and receive the reply resulting from that request. Then it's closed.
On the other hand, all "file driver" based connections require a persistent connection. When the "network is down" so is your "file driver" connection, regardless of whether that file-driver is a .TPS driver an .SQLITE driver, an .MSSQL driver, or any of a myriad of "file drivers". They all use .NETWORK connection protocol.
Nothing wrong with network protocol at all, it's FAST and generally reliable, but over long distances its prone to failure due to connection latency that results from distance and/or infrastructure irregularities and glitches along the connection path.
SQL Server reliability is better than .TPS over long distances, but not really totally reliable without an expensive data connection infrastructure which BIG companies can probably afford, but small outfits mostly can't afford. Even then, SQL Server connectivity is overrated when it comes to most Clarion developers and their data.
CHT data servers belonging to our "next generation" of CHT templates and classes, totally remove NETWORK PROTOCOL over the standard internet from the data-transfer equation.
CHT servers sit, locally connected to their data using Clarion data drivers and network protocol. But data clients do not rely on network protocol to communicate with these CHT data servers. They instead, use HTTP protocol to interact with CHT data servers.
The work we've done recently, tests and corroborates that we can get data in and out of our data servers just as fast as file drivers can when connected locally and considerably faster and waaaaaaaaay more reliably when connected remotely over the standard internet.
One-piece apps that connect directly to data via network protocol and standard file drivers are just so 1980's!
Two-piece apps (client app + server app) that connect to data using HTTP protocol are, as far as we're concerned, the "next generation" of data apps, because they scale from LOCAL to WAN to INTERNET without the developer needing to overly concern himself/herself with the reliablity of the infrastructure.
The Clarion Handy Tools Page
CHT Template Docs
CHT Application Docs (Complete)
CHT Utility Applications Docs
CHT Batch-Bot Application Docs
CHT Snap-In Application Docs
CHT Classes Docs