The Wiert Corner – irregular stream of stuff

Jeroen W. Pluimers on .NET, C#, Delphi, databases, and personal interests

  • My badges

  • Twitter Updates

  • My Flickr Stream

    20140508-Delphi-2007--Project-Options--Cannot-Edit-Application-Title-HelpFile-Icon-Theming20140430-Fiddler-Filter-Actions-Button-Run-Filterset-now20140424-VMware-Fusion-6.0.3.-no-reclaimable
    More Photos

  • Pages

  • All categories

  • Enter your email address to subscribe to this blog and receive notifications of new posts by email.

    Join 1,994 other followers

Archive for the ‘The Old New Thing’ Category

« Previous Entries

Interesting insights by Andreas Hausladen Twitter on the Delphi splash screen process, license file handling

Posted by jpluimers on 2020/05/05

Interesting insights from [WayBack] Andreas Twitter: “I was joking about #Delphi’s splash screen to be shown later so Embt can claim that it finishes much faster now. Today my Internet was down and guess what I had to “witness”. Seattle: 22 sec splash screen time Tokyo: 2 sec splash screen time Sounds fantastic, but…… https://t.co/FGtnJQZDyc”:

  • in earlier versions part of the copy protection (WinVerifyTrust calls) were done after the splash screen was visible and now they are done before.
  • That the WinVerifyTrust call took so long was because Windows (not Delphi) wanted to check for revoked certificates in the first WinVerifyTrust call (due to the missing only-cache flag) and my router seems to not like it if the modem doesn’t have a connection/link to the provider
  • consider using FILE_FLAG_DELETE_ON_CLOSE so that if the IDE is killed during its start (debug session when you see that you forgot something and want to abort) doesn’t wait ~3 minutes or more until the lock is lifted

More relevant links based on the above:

Via [WayBack] Anyone else saw the video on this Andreas Hausladen post? – Cesar Romero – Google+ where I found this observation interesting:

My vm installs have zero net on by default, host only lan, lan only, and internet provided on demand. I’m noticing a lot of differences in the splash screens of 10.2.2.2.2, often lacking registration confirm info (making me nervous).

–jeroen

Read the rest of this entry »

Posted in Development, Software Development, The Old New Thing, Windows Development | Leave a Comment »

Optimizing BitBlt by generating code on the fly – The Old New Thing

Posted by jpluimers on 2020/03/25

Blast from the past machine generated code by the various assembly versions of the  [WayBack] Windows BitBlt function [WayBack] Optimizing BitBlt by generating code on the fly – The Old New Thing.

Via: [WayBack] Rodrigo Ruz on Twitter: “Optimizing BitBlt by generating code on the fly https://t.co/gWmKjex20i”

–jeroen

Posted in Development, History, Software Development, The Old New Thing, Windows Development | Leave a Comment »

User Experience topics like “Why does Explorer use the term KB instead of KiB”

Posted by jpluimers on 2020/03/24

Designing for a good user experience is hard, especially to programmers. So if you are a programmer, please read, let them sink in, rinse, repeat the below linked articles multiple times. Being ~15 years old, they are still so very relevant:

–jeroen

Posted in Development, Software Development, The Old New Thing, Usability, User Experience (ux), Windows Development | Leave a Comment »

Why does HRESULT begin with H when it’s not a handle to anything? – The Old New Thing

Posted by jpluimers on 2020/02/06

Interesting bit of history: [WayBack] Why does HRESULT begin with H when it’s not a handle to anything? – The Old New Thing.

TL;DR:

  1. It used to be a handle
  2. Few programs cared about the underlying objects
  3. Managing the underlying objects was way too expensive
  4. It got trimmed down to a number, but the name stuck

–jeroen

Posted in Development, History, Software Development, The Old New Thing, Windows Development | Leave a Comment »

Delphi, decoding files to strings and finding line endings: some links, some history on Windows NT and UTF/UCS encodings

Posted by jpluimers on 2019/12/31

A while back there were a few G+ threads sprouted by David Heffernan on decoding big files into line-ending splitted strings:

Code comparison:

Python:

with open(filename, 'r', encoding='utf-16-le') as f:
  for line in f:
    pass

Delphi:

for Line in TLineReader.FromFile(filename, TEncoding.Unicode) do
  ;

This spurred some nice observations and unfounded statements on which encodings should be used, so I posted a bit of history that is included below.

Some tips and observations from the links:

  • Good old text files are not “good” with Unicode support, neither are TextFile Device Drivers; nobody has written a driver supporting a wide range of encodings as of yet.
  • Good old text files are slow as well, even with a changed SetTextBuffer
  • When using the TStreamReader, the decoding takes much more time than the actual reading, which means that [WayBack] Faster FileStream with TBufferedFileStream • DelphiABall does not help much
  • TStringList.LoadFromFile, though fast, is a memory allocation dork and has limits on string size
  • Delphi RTL code is not what it used to be: pre-Delphi Unicode RTL code is of far better quality than Delphi 2009 and up RTL code
  • Supporting various encodings is important
  • EBCDIC days: three kinds of spaces, two kinds of hyphens, multiple codepages
  • Strings are just that: strings. It’s about the encoding from/to the file that needs to be optimal.
  • When processing large files, caching only makes sense when the file fits in memory. Otherwise caching just adds overhead.
  • On Windows, if you read a big text file into memory, open the file in “sequential read” mode, to disable caching. Use the FILE_FLAG_SEQUENTIAL_SCAN flag under Windows, as stated at [WayBack] How do FILE_FLAG_SEQUENTIAL_SCAN and FILE_FLAG_RANDOM_ACCESS affect how the operating system treats my file? – The Old New Thing
  • Python string reading depends on the way you read files (ASCII or Unicode); see [WayBack] unicode – Python codecs line ending – Stack Overflow

Though TLineReader is not part of the RTL, I think it is from [WayBack] For-in Enumeration – ADUG.

Encodings in use

It doesn’t help that on the Windows Console, various encodings are used:

Good reading here is [WayBack] c++ – What unicode encoding (UTF-8, UTF-16, other) does Windows use for its Unicode data types? – Stack Overflow

Encoding history

+A. Bouchez I’m with +David Heffernan here:

At its release in 1993, Windows NT was very early in supporting Unicode. Development of Windows NT started in 1990 where they opted for UCS-2 having 2 bytes per character and had a non-required annex on UTF-1.

UTF-1 – that later evolved into UTF-8 – did not even exist at that time. Even UCS-2 was still young: it got designed in 1989. UTF-8 was outlined late 1992 and became a standard in 1993

Some references:

–jeroen

Read the rest of this entry »

Posted in Delphi, Development, Encoding, PowerShell, PowerShell, Python, Scripting, Software Development, The Old New Thing, Unicode, UTF-16, UTF-8, Windows Development | Leave a Comment »

« Previous Entries
 
%d bloggers like this: