Home | Shorter Path | About Me
Home
About Me

Archive

2004

01

02

03

04

05

06

07

08

09

10

11

12

 

2005

01

02

03

04

05

06

07

08

09

10

11

12

 

2006

01

02

03

04

05

06

07

08

09

10

11

12


Archive for 02/2004

Guidelines
Sunday, February 29, 2004 11:12 AM

If you're thinking about developing class libraries for .NET, take some time and read the Design Guidelines for Class Library Developers. The guidelines are also included in the SDK documentation.

 

.NET's own private DLL hell
Wednesday, February 25, 2004 12:33 PM

Using strong-named assemblies means no one will break your application by upgrading third-party assemblies. At least in theory. Read more...

Reading the news
Wednesday, February 25, 2004 11:28 AM

So, I finally switched to XanaNews as my newsreader for the Delphi newsgroups. I have to say, Colin has done a great job. As a TeamB member, I spend a lot of time in these newsgroups, so switching from Agent wasn't easy. Still, XanaNews made the transition fairly painless.

The great thing about XanaNews, for me, is that Colin really figured out what are the things that interest heavy newsgroup readers, then made them easy. XanaNews highlights groups and threads that require my attention (for example, because someone replied to my post). It lets me go back to the previously viewed message, which is incredibly useful when you're reading hundreds of posts per day. Sometimes you're just going through unread messages, trying to find something interesting, when you realized the post you've clicked through could be just that, only it's buried in a huge thread somewhere. One or two clicks on the Back button, and I'm there. Also interesting are the special tools, like Forensic Mode. Viewing messages in forensic mode can be quite educational, even surprising.

My only problem so far is that XanaNews can be slow at times. It actually downloads messages a lot faster than Agent, but there's a slight delay when moving between groups. Still, it's a minor inconvenience compared with all of the great features.

.NET vs Win32 - Really?
Sunday, February 22, 2004 04:39 AM

One of the things people keep telling me about .NET is that Microsoft had announced that Win32 will only be supported as an emulation layer in the next version of Windows ("Longhorn"), so we should all migrate our existing applications to .NET. Unless they're friends, or people I really don't want to hear from ever again, I can't really laugh at their face, so I have to give some reasonable answers. Here are some:

1. It's just not true. As of today, Microsoft deosn't plan to reimplement Win32, Win64, or any other native API as a managed API. On the other hand, Microsoft does plan to provide new managed APIs that will not necessarily be available to unmanaged applications. (Take a look at this message posted to Borland's newsgroups).

2. Even if it was true, it won't break my code. If ever there was a software company that invested heavily in backward compatibility, it's Miocrosoft. Just take a look at the amount of code in Windows 95 to detect specific application and change the operating system's behavior for them. In fact, Windows 95 reports its version number to applications as 3.95 (and not 4.0), just to work around a common bug that incorrectly tested for Windows 3.1. There's just no way Microsoft would break the Win32 API.

3. Win32 is already an emulation layer. Most Windows programmers aren't even aware of this fact, but Win32 isn't really the native API in the NT family of operating systems (Windows NT, Windows 2000, Windows XP, and Windows 2003). NT uses a modified microkernel architecture, and Win32 is implemented as a subsystem that provides applications and services with the Win32 API, which it then translates into "native" system calls. If you look at the list of processes in the Task Manager, you'll find several interesting processes, such as smss.exe, the Session Manager Subsystem, which creates NT's user-mode environment and loads other subsystems. The Win32 sybsystem is implemented by csrss.exe (Client/Server Runtime Subsystem), and several DLLs, such as KERNEL32.DLL, USER32.DLL, and GDI32.DLL. NT's real API (sometimes known as the native API) is accessible through NTDLL.DLL, which doesn't really implement it, but triggers software exception to switch the code into kernel mode.

In fact, Win32 is just one of several subsystems supported by NT. NT's designers built the system as a sort of operating system musuem, and included several other subsystems, such as OS/2 and POSIX (how many POSIX applications do you have on your system, by the way?). The bottom line is that Win32 has always been an emulation layer, and I don't see that changing. And unless Microsoft want to commit suicide, they won't break it.

VCL.NET
Thursday, February 19, 2004 07:28 PM

Danny Thorpe from Delphi R&D explains VCL for .NET. This should get the Delphi newsgroups stirred up.

Planners
Tuesday, February 17, 2004 12:00 AM

We've just released a new component library, Planners for VCL. It's a set of planning components that let you integrate scheduling user interfaces into your Delphi, C++Builder, and Delphi for .NET applications.

A full-featured trial version is available here. The trial version only runs in the IDE, but its functionality is not limited in any other way.

Haunted by the Past
Sunday, February 15, 2004 11:22 PM

Anyone writing code in the real world has, at one point or another, to work on someone else's code. In such a case, a programmer's first instinct is to find some excuse to throw the code away and start from scratch. Other people's code, you know, is never properly organized, commented, or doing what it's supposed to do. Sure. Joel Splosky refers to this problem as a fundamental law of programming: It's harder to read code than to write it.

Last week I was faced with this problem, but with a twist. A customer wanted a specialized Delphi control, and I was happy to oblige. The control would be integrated into an existing library, a great deal of which I have written myself for that customer almost seven years ago. During these seven years, however, other programmers have maintained the code. And even though it was beutifully written (of course), they still found ways of making it unreadable. It was like looking at a warped mirror: you can recognize yourself, but you don't really look like that.

I struggled with the code for a few minutes, and didn't get anywhere. Anything I touched caused an error or didn't work as expected. So I stepped back and though about it, and then it dawned on me: I wasn't really reading the code. Instead, I was trying to figure out the differences between the code and what I've originally written. The problem is that this approach only works when the code is fresh in your mind. It's been seven years since the code was fresh in my mind.

Once I started reading the code as if it was all someone else's work, things fell into place. It took me less than 20 minutes to finish the integration and test it. But I still wished I could throw the old code away.

Useful information
Sunday, February 15, 2004 04:24 AM

A noble spirit embiggens the smallest man. I just thought you should know.

Blocking Programmers
Friday, February 13, 2004 06:16 PM

Julian Bucknall writes: "You're faced with a blank editor page in your IDE and nothing comes. No brilliant connection from requirement to design, let alone to implementation. Just stuck. Why is this?". He goes on to suggest several reasons (and solutions), both technical and psychological.

I think Julian ignores an important factor: programming is creative work. As a programmer who's experienced may blocks in the past (and will probably experience them in the future), I can think of two reasons for programmer's block resulting directly from this factor.

Read more...

Conversion tips for VCL.NET
Wednesday, February 04, 2004 12:40 PM

I've been working on upgrading some VCL components for Delphi 8, and came up with some tips for converting VCL components to VCL.NET.

Copyright 2004 Yorai Aminov