This is the final part of Type Systems Demystified which explores strong typing and type safety issues. It is a multi-language and comparative approach using Perl,C,C# and VB.net with a strong emphasis on Perl
I wanted to take a look on printing Unicode on the windows console by using the Win32 api and also check how is done in other languages, rather than directly from Perl which hides a lot of details
Problems when wanting to print to the console :
1.The windows console uses an internal buffer that can mangle output
2.Invoking the console using the Unicode switch (cmd.exe /u) does not have an effect
3.Windows supports UTF-16 inherently, not utf8
4.Documentation on Unicode and the console is hard to find.MSDN library, as usual, is a labyrinth with no beginning and end where you can loose track easily
The need arose when I needed to print an old style dos box using the cp437 box drawing characters on the console using their Unicode code points rather than their ASCII representation. The output was mangled/overlapped
Part 1 of Type Systems Demystifed was released. It explores dynamic and static typing.
Link: Type Systems Demystifed
"This article is intended to help to someone who has a dynamic language background and wants to jump into the .NET platform, someone with VB.NET experience that wants to know how things work in C#, the C# programmer interested in dynamic programming, and any programmer who wants to know how type systems work."
Part 2 of Type Systems Demystifed was released. It explores weak and strong typing.
Link: Weakly typed languages
"Weakly typed languages
In Part 1 of this series we explored and compared the static and dynamic systems. Now we are going to focus on weak and strong typing and discover once more that the boundaries (which languages are considered strong and which weak) are not clearly defined."
PC's with Windows OS run terminal emulators which connect to Unix/Linux servers. When the ABF application generates a report its output is dumped on disc as a plain text file which is subsequently send to a network or local printer.
When local printing is required (the printer is attached locally to the PC running the emulator) then the emulator opens a direct connection to the local printer port by using special escapes (called transparent ot pass-thru printing) and then forwards the plain text file to it.
In either case the file is forwarded to the printer in RAW format, bypassing any printer drivers and thus is printed as-is. The same process holds also true for reports generated by OpenRoad on Windows
The disadvandes of this approach are :
although sent in RAW format, the interpretation lies on the printer at hand;
for example some printers cannot translate…
A nice presentation on Eweek summing up Perl's past, present and future.
Coupled with Tim Bunce’s Perl Myths , demonstrate that not only Perl was never dead but also that ,at milestones throughout time, gets rejuvenated