PERL,INGRES,PROGRAMMING

Just released an article on  i-programmer called Unicode issues regarding the Window OS file system and their handling from Perl Intro : " Unicode is supposed to make character handling easy, but living with a legacy system that uses multibyte encoding makes things complicated. This article looks at  the real world of Perl Unicode integration and exposes a set of problems that also occurs in other languages and systems. "

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 Take a look at this pictorial output to get a clear view of the problem The code that generated the incorrect result is : #unicode_box_incorrect.pl use Win32...

Lots of people (me amongst them) use Perl modules on Windows that interface with the Win32 API and the most usual problem is with Unicode since some modules call the Ansi functions and not their Unicode equivalent counterparts. Not only this, but the actual job that they are after can be achieved much easier by using facilities readily provided and embedded within Windows itself. Specifically the COM automation is a great tool for performing myriads of activities, be it monitoring all aspects of the system using WMI, monitoring an Active directory environment using ADSI, working with files (most Unicode related problems start here) with Filesystemobject or fiddling with the network and DCOM using WSH. The automation abstracts the API , makes work easier and is more tolerant to errors in contrast to their API counterparts. All of that can be used through the Win32::OLE module. I'm not saying not to use modules that interface with the API, there are many cool ones,and speciali...

(Read a complete article on the matter and much more " Unicode issues regarding the Window OS file system and their handling from Perl) Currently there is no way to manipulate a file named using Unicode characters,by using Perl's built in functions. The perl 5.10 todo wish list states that functions like chdir, opendir, readdir, readlink, rename, rmdir e.g "could potentially accept Unicode filenames either as input or output". Windows default encoding is UTF-16LE,but the console 'dir' command will only return ANSI names.Thus unicode characters are replaced with "?" ,even if you invoke the console using the unicode switch (cmd.exe /u),change the codepage to 65001 which is utf8 on windows and use lucida console true type font which supports unicode. A workaround is to use the COM facilities provided by windows (in this case Scripting.FileSystemObject) which provide a much higher level of abstraction or use the Win32 api calls. I tried to re...

The development of 4GL Ingres applications happens on Unix.Access to the Unix environment is made possible through windows terminals using a terminal emulator . When printing a report from inside the 4 GL application , the application calls the 'system' command which passes arguments to the 'report' command.The actual report is run and the output is being redirected to the local printer on windows by sending escape sequences to the terminal emulator which open the local printer port and send the data (pure text) to it in RAW format with no translation whatsoever by the windows driver. The problem is that the report looks not 'pretty' as it consists of dots and dashes acting as placeholders for the textual data. The presentation would be much better in another format like HTML. The plan was to : add HTML tags inside the actual report file,before it is run,so the dot and dashes would be replaced by the tags. In practice each .prln or .pr report co...