Monday, December 17, 2007

Lesson from a collapsed games company

Recently, a software games company in Brisbane, Australia, called Auran, announced that it has called in the administrator and a large number of staff laid off. Among the somber news of a collapsing company, several revealing comments from its Chief executive in explaining the collapse that should serve as a real-life evidence to support principles that have been widely known in software engineering text book, but conveniently ignored by many:

"Certainly we spent far too much developing the game. We spent $15 million and basically it came down to too much rework . . . and even then we didn't get it quite right in the end," he said.

"If you overspend creating your product and you run out of money and you release it unfinished you end up closing your studio down."

Let this be edged in any manager's mind and as a warning beacon when he/she is tempted to rush out product with a naive invincibility that he/she can come back to fix them up later.

Friday, December 14, 2007

Watch out when using Form Derivation in VCL.Net

This is another case where it's important to examine the implementation in greater detail than accepting the fact on the face value.

Both VCL.Net and Win Form, including Delphi Win Form, support form inheritance. But their implementation and deployment support models are poles apart.

In Delphi, you must ship the source code of your base forms to your customer in order for them to derive from it and to author their derived form in the IDE. In order to view each derive form in the IDE (D2007 included), you must first open its ancestor form in the IDE. Otherwise you'll receive am error dialog box.

This is only the requirement of the IDE. The framework works fine at runtime if the controls on the derived form are created and rearranged dynamically at runtime.

Contrasting this to Win Form, even Delphi Win Form in D2006, there is not such requirement to ship source code. To derive from a form packaged in another assembly, all you need is to reference that assembly and that's all to it.

So it's important when comparing features to look deeper than the glossy brochure.

IT managers blamed for making staff sick

Can agree more with this finding:
the most widely experienced management styles in the IT sector are reactive (45 percent), bureaucratic (38 percent) and authoritarian (24 percent) -- styles that can all have a negative impact on workers' morale, productivity and even health.

....those which seek to empower staff and encourage a supportive and open workplace culture -- are better for business as they can boost staff morale and productivity. ..."Where cultures are more innovative or more proactive, there's generally greater motivation in organisations."

More than a third (37 percent) of organisations that are performing well have "accessible" management teams, whereas more than half (56 percent) of declining companies display bureaucratic tendencies and a quarter have a "secretive" environment.

Bad management can also be blamed for workplaces where a "sick-note culture" exists.

JVC's MOD file is actually a MPEG-2 file.

Recently, I have acquired a JVC hard disk digital video camera and it creates files with .MOD extensions.

So I am interested to find out what kind of files they are.

Searching the internet, I found this great tool called GSpot. Not only does it tells you what format (video + audio) plus a plethora of other technical data, it also informs you if you have the codec to decode it. This tool quickly identifies the .MOD file is actually a MPEG-2 file and that my machine does not have the codec for it.

My friend recommends me to use the K-Lite codec suite. Once the suitable codec is installed, renaming the .MOD to .MPG allows me to play it on Windows media player.

Wednesday, December 12, 2007

Vista Security one year on - still not tools to help developers

Recently there is an article published that discusses various security features of Vista and how they are accepted.

With respect to the UAC, the author has this to say:
One reason for the condemnation is that many administrators believe that a lot of legacy applications are programmed to have free reign over the system; truth is, however, they end up not being compatible with Vista.

Windows professionals require elevated permissions to perform elevated tasks. Those tasks are more difficult when administrators are treated like common users. Hence, more criticism.

Even though User Account Control can be annoying at times, I think Microsoft had no choice -- it had to create this feature. Windows XP had such a bad reputation in regards to how easily it could be infected with malware that Microsoft made sure Vista was designed in a way that would prevent malware from taking over the system.

Well, some of the argument the author used is totally wrong.

There is no excuse for developers at the end of year 2007 not to be aware of the Windows Security Model that was first released with Windows 2000. If they are unable to learn by now and most I dare to assert aren't even aware of the security specification, the OS should simply banish them.

XP is given such a bad name because these developers are not well educated. Their ignorance influences other users to turn off the security model. I once questioned a well-known accounting software package why it required Administrative Rights to run and what privilege operations that needed such high level of demands. Of course, I was told it needs Admin rights. On deeper investigation, it turned out the software company was more interested in protecting its license than to protect the users machine and data by using a licensing protection software technique that obviously was poorly developed as that was the part that demands administrative rights.

Developers should not shoulder all the blame for the creation of this mess, Microsoft should share a major portion of the blame in several areas:
1) Microsoft attempts to make things easier for ordinary users by opting to allow user to run wild with no security - the easiest way out. Have you ever seen a Windows installer that when adding a new user defaulting to non-Administrator accounts?
2) Why isn't there any auditing of violation? or interception of invalid calls and logged them into event log. At least this can allow developers to have a chance to see any invalid or security violating calls.
3) Microsoft built the tools that most developers use to develop Windows software and why that tool does not have any debugging hooks to watch for this kind of violation or excessive demand of rights? And in the latest version still does not have any. In .Net 2, the debugger can pick up cross thread UI calls when using WinForm. It is at all possible. Just look at how Vista virtualizes some of this calls that would be invalid in XP running in limited users account. If it can virtualize those access to HKLM or protected folders, why can't it write an event log entry or picked up by debugger?

If Microsoft has attacked this problem when Windows 2000 is first released, by now there would not be a need to waste so much resources just to help out ignorant and arrogant developers who not only are not conversant with the security model but also are not using the operating system properly.

I have been doing all sorts of development in LUA (Least-Privilege User Account) for years now and have not encountered any issue. Sure I have to enlist Administrative mode to do certain task but in most other time, LUA is fine. The most annoying things are software package that fails to comply with LUA from large software development house, some are documented in this blog, that you would expect them to know better.

Why doesn't Microsoft host the 'Hall of Shame' of security violators much like the Hardware compatibility list?