MSK Software Development

Es geistert nun endlich die Idee eines Zweckverbandes bzgl. Breitbandanbindung in den Zeitungen herum. Diese Idee ist ja nicht neu - immerhin haben sich die ersten Ideen zu diesem Projekt vor bereits einem oder zwei Jahren entwickelt - nur damit man mal die Geschwindigkeit dieser Entscheidung “relativiert”.

Die Investitionssumme ist enorm und ich kann mir auch vorstellen, dass - wie bei allen Planungen - diese Summe nett gerechnet wurde und wirklich nur ein erhofftes Ziel darstellt: 150 Millionen - aber daraus können sicherlich auch 180 oder 240 Millionen werden !?

Es gab ja auch Planungen, dass im ersten Schritt nur die Gemeinden mit Glasfaser erschlossen werden - nicht die einzelnen Haushalte, was die Kosten ja erheblich reduzieren würde. “Vor Ort” - sollten dann alternative Anbindungen (Telekom, Funk) gefunden werden - allerdings wird man keine kommerziellen Anbieter finden, die vielleicht nur 50 oder 75 Haushalte anschliessen wollen. Man hätte dann zwar Glasfaser im Ort - aber keiner profitiert davon.

Der Anschluß von Einzelhäuser wird dann auch eher im Aufgabengebiet der betroffenen Gemeinden bleiben.

Allein - noch ist nichts entschieden und alle Bürger sind aufgerufen, ihren Gemeindevertretern den Ernst der Lage vor Auge zu führen und sie zu drängen dem Projekt beizutreten. Außerdem sollten die Vertreter darauf achten, wie die Dörfer und die Haushalte wirklich angeschlossen sind. Ein Anschluß an dieses Netz schützt auch unsere Immobilienpreise.

Denn eine Nebenwirkung hat dieses Projekt auch - wie alle kreisweiten oder landesweiten Planungen: unterhalb der Planungsebene wird sich in Sachen Internetanbindung nichts mehr bewegen - man schaut die Hierarchie hinauf und wartet ab - wie ich schon seit 10 Jahren die Politik hinaufschaue … und auf eine schnelle Anbindung warte.

Vielleicht kann man die Bewilligung, Planung und Ausführung dieser Aktion dadurch beschleunigen, dass man alle an diesem Projekt beteiligten Personen im eigenen Hause erst einmal den DSL-Zugang kappt und sie zwingt, nur noch mittels ISDN zu surfen - ich vermute, dass das Projekt dann wirklich “turbo”-mäßig realisiert werden wird

Aber um auch Mut zu machen: wer aus der Vergangenheit lernt, der wird auch verstehen, dass derjenige bestimmen kann, der die Infrastruktur besitzt: das gilt für Strom, Wasser, Gas, Strassen, Bahntrassen und Telefonleitungen.

Übrigens: Von den Funkprojekten hat man nichts mehr gehört - im Bezug auf Kleve.

Windows has support for 64bit timers - giving you the chance to have a more accurate timing source. Here is a source code example to use the available API calls:

frequency := OSUInt64 new.
firstTick := OSUInt64 new.
secondTick := OSUInt64 new.
(PlatformFunctions::QueryPerformanceFrequency callWith: frequency)
  ifTrue:[
   (PlatformFunctions::QueryPerformanceCounter callWith: firstTick)
     ifTrue:[
      (PlatformFunctions::QueryPerformanceCounter callWith: secondTick)
        ifTrue:[ Transcript cr ; show: 'Overhead API call:',(((secondTick at: 0) - (firstTick at: 0)) / (frequency at: 0)) asFloat asString,' in sec' ]
        ifFalse:[ Transcript cr ; show: 'Error retrieving secondTick :',MSKOperatingServices GetLastErrorMessageOrNil asString ]]
      ifFalse:[ Transcript cr ; show: 'Error retrieving firstTick :',MSKOperatingServices GetLastErrorMessageOrNil asString ]]
  ifFalse:[ Transcript cr ; show: 'Error retrieving frequency value :',MSKOperatingServices GetLastErrorMessageOrNil asString ]

On my machine (2.6 GHz - Windows XP, Intel Dual-Core) I get an API overhead time of about 3.5 * 10^-7 seconds, when changing the last both callWith to asyncCallWith: I will get 2 * 10^-5 seconds for each call - meaning,that the asyncCall is 100 times more expensive than the synchronous callWith call.

On my home machine (2.2 GHz - W7/64, Quad-Core) I get 5*10^-5 sec for asyncCall and 9.3*10^-7 sec for syncCalls …

For more information about this API you may read here or here

I’m happy to announce a new version of an OpenGL wrapper library for VASmalltalk. My very, very (!!!) special thanks to Sebastian Heidbrink, who took my original code and did a complete rewrite of the GUI/widget layer and made it work in a more robust way.

I’ve published it at vastgoodies and hope, that users might find it useful.

The wrapper is now based on several configuration maps. The users should look at the maps “MSKOpenGLSupport Runtime Loading” and “MSKOpenGLSupport Examples” and all their prerequisites.

To load the OpenGL wrapper you should load the first map, for examples of usage of this wrapper you might load the later one. The map with examples are pretty large - due to embedded resources of images.

There will also be a “MSKOpenGLSupportRuntime Vector Loading” in the future. This map loads the runtime, but with the basic OpenGL data types based on my vector extension.

For building GUI’s with OpenGL you will find an OpenGL container based on a top level shell and another widget for usage in the CompositionEditor. Examples are available to show how to use these classes.

Today we published the version 0.7 at the repository mentioned above.

Known issues:

- on some computers there is a problem with opening a valid OpenGL windows when doing it for the first time. I have a 0.7.3 version here, where I could get rid of it.

- we will do changes in all the parts of the code we published.

The last image shows the stuff running under Linux/Wine also !