As I mentioned in my posting in July: the ARM (even at 624 MHz) is too slow to get all done with a 480x640 screen. During last weeks I played around with viewing on a device like this.

It is useless to render the movie for 480x640 - it makes the file much bigger and one does not get that much better quality - and at least the N560 is not able to play that movie smoothly AND play also the sound of that movie.

Switching of the sound and the N560 is able to play that movie again - without problems. I decided therefore for myself just to render the movies for that old 240x320 format - the quality is about the same and sound is also ok then.

The conversion still takes hours to be done ... but that's a problem for the desktop PC ....

When I bought my N560 with a resolution like this I was surprised to see, how the refresh of that screen feels much more slowly  as on my old ipaq2210 (with PocketPC - 2003-2nd). Yesterday I played again with the ipaq2210 and to my surprise: the screen feels speedier than my new N560.

There are users out there, who also noticed this problem and some people say, that one does not really need that high resolution on a mobile device - and I can understand, that they are perhaps right. You have the same screen size and you can not make the buttons much smaller - because it gets not very confortable to press such small buttons with that pen and even with your fingers. This is perhaps the most interesting user experience ! But I also notice, that the companies have to make marketing ....

One the other side I also notice, that tools like Opera are better with that solution, because they can show you much more (on that small screen with much smaller fonts) - if you are still able to read these small fonts.

Therefore it may be a good idea (if you consider to buy such a device) to buy a WM5 system, which gets help from a special graphics processor. 

One the most annoying things with VS2003/2005 are the problems, when the designer can not show you the form you are working on - it then shows some exception stack.

This is very strange for such a tool (you can still build the application, let it run - without any problems - but you can not edit the form) - most of the times I think, that this only happens, when the forms are really getting complex (several tab pages) or you use custom controls.

When you are in situations like this - do not give up. You may use the following way to rid of the problems (but perhaps you need to do this several times) - like this morning:

• Close all opened source code files, especially ALL shown forms
• Close VS 2005
• Open VS 2005
• Open Project
• Rebuild the whole system

Now I had the N560 and I looked for a suitable SD-Card for this PDA: I heard about trouble when using large SD cards. I bought a takeMS SD-card 4GB 133x and it works very well in this PDA. Reading the Siemens news groups there seems to be the possibility to have problems with larger cards than 2GB. Just as an information - it works !

Marten

Ok, MS was our cooperation partner. MS was really interested to get our project one. We were offered additional tools, conference visits and direct connection to german supporter to solve our problems - what do they expect ? Officially nothing, but internally it was made clear, that MS tools should be used unless the project is in danger - and we should (please, please) not use OpenOffice.

We got the chance to speak with several MS technology supporters here in Germany and all these persons were highly general qualified persons - without any doubt and it was always a pleasure to talk with them.

Perhaps their main problem was, that they - of course - must sell MS products.

The main interesting aspect with working with MS was, that they have a complete different way to create solutions:

"The graphics could be done by using GDI+ and perhaps we use the 'MSWindows 2003 server', then the SQL server and the Reporting Services. Of course we should use BizTalk and ... and ... XML ... and ... and one should consider the usage of MSOffice Suite as an user interface"

Top Management was excited about all the possibilities we get by using all these products, but we as the developers were not so satisfied - the system got more complex than we wanted and all those tools - the license questions and so on. After all there were only two persons, who should maintain this system .... and debugging of systems like this are not easy at all.

We wrote a note to management about the possible license costs we would have to pay then (boy - a nice amount of EUR !) - and the answer was: it does not matter (sometimes it is difficult to get an USB stick for EUR 20 - and now ...), but we got from other managers the hint, that we should take the license costs into account - the partnership with Microsoft is time limited and after that license costs could be a problem.

One interesting thing was, that MS could not help us very much, when we left the MS technology or we got too deep into details - as an example: what happens, when we want to use "OpenGL", how is the behaviour of the .NET garbage collector during realtime graphics display ? In general it means: go the Microsoft way and do not take any other technology into account.

One other interesting aspect is, that when you take one server product from Microsoft you end up with all other server products.

We considered all ideas, but after all we went our own way:

* Storage is done in simple files on a normal file server. No SQL server

* No SQL server -> no Reporting Services

* No WWW interface -> no BizTalk

We also did (recently) some tests to include "MS Office 2003" and actually this was not really a problem. I started the development under "MS-Office 2003" - but my partner used "MS-Office 2000" and there we had first problems. .NET and "MS-Office 2000": no support from Microsoft. It should be at least MS-Office 2002 (MS Office XP). We "googled" again and the answers were pretty simple again:

* do not do it !

* program against the oldest office suite you want to support and try to cover the newest one via tests.

We throw support for "MS-Office" out of our product.

VS2003 came with full MSDN (and all those DVDs and CDROMs) and we began to start. We played around with the system, made small applications and then we looked at our source code management.

We were no Windows developer (just Smalltalk) and therefore in the past we were forced to use the Windows API in an extensive way - but were are also not used to the "under Windows we do it this way ...".

Used to ENVY, we expected very much from our source code management and we looked around - Visual SourceSafe.

We installed it and after some days of working, both of us were not satisfied with this tool - and the (for us) unusual usage.

We "googled" and found lots of negative comments about this tool. Actually we did not blieve, that CVS was much better and we looked further on in this topic.

We looked for source code repositories and we did not find reports about software like this under Windows developers. We did not understand that at all - I read newsarticles and newsarticles and for me, its now very simple:

"DO NOT TOUCH MY ASCII SOURCE CODE" - was one of the sentences I've found in the newsgroups and this reflects the opinion in the Windows developers world pretty good.

This is very interesting and I really would like to know, why the worlds are so different. Linux, C, C++, Java, .NET -- all work with these old-brained CVS like tools.

The only reason I find for myself is, that these tools are in general freeware - and they are very often usable for distributed development.

But the tools developer know, that they are missing something and they do everything they can to get around the limitations of these source code managements. "All implementer", "all callers", refactorings is pretty difficult for them to do ....

Another limitation (of VS2003) was the "one class - one file" idea. Lots of tool producers had lots of problems with this limitation, which is gone with VS2005.

We then found Subversion and used this tool as our repository. Its not ENVY, but it is easier to handle as SourceSafe. The VS2003 subversion client works - but we still have trouble with it - therefore we in general use the Explorer (with its addon) to manage our source code.

Now TeamServer is out - but look at the software/hardware requirements. Typical for MS. You want to have one product and you have to buy several system components to make it work.

The prices are high and management is not that happy: "do you really need it ?"

The critical point "source code management" is in my opinion one of the most underestimated problems in the software development world - and even our IT oriented management is not very interested in this point.

"Hundred of millions of developers work with SourceSafe - why do you have somany difficulties ???"

"Live" Conditions

Have you ever worked under "live" situations? Our tool was used in television studios during special events and this in general means: "live" conditions.

Working under "live" conditions in television studios is something like taking drugs and alcohol at the same time (I assume). "live" means: no errors, no bluescreens, no database problems, no problems at all and whatever you do: millions of viewer see the result of your work. Nice feeling.

My first experience I had with this special circumstances was somewhere around autumn 1997 - when our Smalltalk program first entered the studios.

We survived - but had lots of trouble ...

Novell-MultiProtocol Router

We had connections from our studio to Munich, where we get our informations and to Berlin where another customer was sitting. To connect these three sites we used a product from Novell - some kind of multi protocol router. A new product they had "ported" from their Novell system to Windows NT4. The software was totally shit - it was maintained by a browser. But by using a browser we notices heavy memory leaks within this product. On the other hand it was everything - but not stable. And much less stable, when not active maintaining it via a browser (resulting again in memory leaks) and sometimes the system uses 100% CPU time and nobody knows why ... during the event we needed ONE person just to maintain this ISDN router - and this was a difficult job.

In those early days when you hang up the ISDN lines there was the possibility that you do not get a new one. During these events there was lots of communication around us (reporters, normal person, other companies, other television companies) and it could also happen, that handy networks were simply overloaded and you did not get a new connection.

Database problems

Another problem was the database. Versant, Argos and database locks - the horror story for me in the last century and even after 6 years we got these locks on a random base (but only very few now). We never found "the" reason for this problem. The only solutions for these problems: stop all running applications and try again. But even then these locks are stil there.

During our first event we had these locks about 15 minutes before we went on air. The situation we were afraid of. First the people (within the studio) try to solve the problem locally, but then they contacted me in the local server room and we had to stop all other person (around 20) using the program and then shut down all connection processes (odb.exe - the name I will never remember) and then the database itselfs. This took quite a time - and the server was ready around 2 minutes before we went on air and the users in the studios were ready around 15 seconds before we starting broadcasting.

We had lots of problems that evening - but we survived and this is also due to the fact, that we used Smalltalk and where able to change the source code while the critical application was running - an amazing and wonderful feeling, even years after that event