Wiso-Software für den MAC

Laut der aktuellen Erhebung für den Juli hatte Mac-OS X einen Marktanteil von 4,86 Prozent.

Das dürfte wohl nicht lohnen.
MfG Günter

Zitat von Burki

Das hat ganz einfach damit zu tun, dass 'Mein Büro' nicht in einer plattformübergreifenden Programmiersprache (wie beispielsweise Java) entwickelt wurde und deshalb eine Mac- (oder auch Linux-) Version praktisch einer Neuentwicklung gleich käme. Letztendlich fehlt hier also der Ansatz einer Konvertierung in andere Betriebssysteme.

Es fehlt nicht der Ansatz einer Konvertierung, es ist eben einfach schlechter Design. Es gibt genügend Software, die auf unterschiedlichen Betriebssystemen läuft und in einer nicht plattformunabhängigen Sprache wie C oder C++ entwickelt wurde. Das geht sehr wohl, wenn man es eben bei der Entwicklung berücksichtigt. Da ist dann ein Großteil der Codebasis für alle Betriebssysteme gleich.

Leider gibt es aber genügend Entwickler, denen das herzlich egal ist, und die erstmal für Windows implementieren und später feststellen, dass es zu spät ist. Das kann sich aber selbst für Windows später gerne mal rächen. Buhl hatte ja z.B. auch schon öfters mal ihre Probleme, wenn eine neue Windowsversion herauskam. Wenn man bedenkt, dass man nur vor wenigen Jahren WISO Sparbuch nicht ohne manuelle Änderungen am System als eingeschränkter Benutzer verwenden konnte, obwohl das Konzept spätestens seit Einführung von XP bekannt war, merkt man leider irgendwie, dass Buhl mit ihrer Software zu Zeiten von DOS (W95,W98) angefangen hat, und bei den Windows-Upgrades weniger in Abstraktion als in zusätzlichen Aufwand investiert hat.

Wir können ja gespannt sein, wann Buhl es schafft, für Ihre Software eine native 64bit Anwendung zu vertreiben und wieviele Probleme es damit geben wird. Ich befürchte ja, aus der Geschichte von Buhl, dass die 32bit überall in Ihren Anwendungen fest drinnen haben und es lange dauern wird, wenn nicht irgendwann doch die komplette Neuentwicklung kommt.

Bzgl. OSX: Ich habe Sparbuch in einer VM von VMWare Fusion. Parallels hat auch was. VirtualBox gibt es kostenlos. Man braucht also nur eine Windows-Installation und eine Windowslizenz. Dann kann man das bisschen Software, was man unbedingt braucht und was unbedingt Windows braucht, auch noch benutzen...

Aber bitte nicht vergessen, dass viele Programme mit Anwendungen wie z.B. Elster usw verknüpft sind, und solange diese nicht auch auf den MAC-Zug aufspringen, ist alles nicht so einfach.

Zitat von SaSue

Ahja, eine Software, welche nur für Windows entwickelt wird, ist schelcht designt. Interessaner Ansatz.
Man könnte genau so argumentieren, weil man sich nur auf Windows konzentriert hat, ist MG so erfolgreich.

Portablen Code zu programmieren, ist in der Regel immer besser, als Code nur für eine Plattform. Das fängt bei so einfachen Dingen an, wie "int" zu benutzen oder eben eine Abstraktion davon, die plattformunabhängig immer dieselbe Bedeutung hat.

Zitat von SaSue

Ahja, und das Certified für VISTA und Windows 7 bekommt man von Microsoft, wenn man für "DOS" programmiert, interessanter Aspekt.

Das eine hat mit dem anderen nichts zu tun. Ich habe nichts darüber geschrieben, für was bestimmte Buhl Software zertifiziert wurde. Wie ich schon schrieb: in der Vergangenheit hatte Buhl schon öfters Probleme, die Software komplett ordentlich auf einer Plattform zum Laufen zu kriegen. Man konnte z.B. Sparbuch nicht als eingeschränkter Benutzer verwenden konnte, ohne manuell die Rechte auf diversen Verzeichnissen und Dateien zu ändern, als XP schon einige Jahre auf dem Markt war und wenn ich nicht irre, sogar schon Vista auf dem Markt war. Ob Microsoft sowas trotzdem zertifiziert oder nicht, steht auf einem anderen Blatt.

Zitat von SaSue

Ja, Buhl hat im Quellcode sicher gleich an erster Stelle
SET_irrevocable_32_bit=true
stehen.

Mal davon abgesehen, dass es mehrere Abhängigkeiten für die Entscheidung 32bit vs. 64bit gibt:
Welchen Grund sollte es geben, MG als Native 64bit Anwendung zu vertreiben?

Ganz einfach: weil es ziemlich sicher in den nächsten 10 Jahren im Prinzip nur noch 64 Bit Anwendungen geben wird und Windows komplett 64 bit sein wird und sich da nur darauf zu verlassen, dass Microsoft alles dafür tut, wie üblich rückwärtskompatibel zu sein, und einfach weiter 32 Bit Anwendungen zu machen, weil es zu aufwendig ist, auf 64 Bit umzustellen, nur weil die Anwendung an tausenden von Stellen bestimmte Annahmen über Pointergrößen fest implementiert hat und deshalb nicht läuft, wenn plötzlich ein Pointer doppelt so lang ist wie bisher...

Zitat von Administrator

Ohne jetzt gvde zu nahe zu treten, möchte ich dennoch in Frage stellen ob er in der Lage ist überhaupt die hier genannten Aussagen zu tätigen.

Was polarisierend ist, ist wenn Du mich hier direkt angreifst, und ohne eine Ahnung von meiner Qualifikation zu haben, und mir Dinge unterstellst, die nicht wahr sind. Ich kenne Softwareentwicklung sehr gut seit über 20 Jahren, und zwar im Bereich von Software, die auf unterschiedlichsten Plattformen laufen musste. Deine Angriffe gegen mich mit solchen Pseudosprüchen wie dem obigen zu kaschieren, ändert daran auch nichts. Ich weiß, dass bei ordentlicher Entwicklung auch Software z.B. in C auf unterschiedlichsten Plattformen und Fenstersystemen laufen kann, mit einem großen Teil identischer Codebasis für alle Systeme.

Ich habe nie behauptet, die Gründe zu kennen, wieso Buhl nur Windows Software anbietet. Ich habe nur Beobachtungen aus den letzten Jahren beschrieben und meine Vermutungen daraus begründet. Es ist ein Fakt, dass Buhl zumindest mit Sparbuch noch Jahre nach dem Erscheinen von Windows XP und sogar noch in die Vistazeit hinein Schwierigkeiten hatte, den Umgang mit der Benutzerverwaltung, eingeschränkten Benutzerrechten, etc. hatte. Was problemslos auf Windows 98 funktionierte, da der Benutzer immer "Administrator" ist, funktionierte auf XP nicht mehr so einfach, wenn man eben die normale Arbeit als eingeschränkter Benutzer machte und nicht als Administrator. Das ist für mich ein Indiz dafür, dass wohl bei der Entwicklung eine saubere Trennung von Programmcode, Programmdaten, und Benutzerdaten nicht von Anfang an gemacht hat. Wenn doch, dann hätte es nicht mehrere Jahre gedauert, bis es umgesetzt wäre. Und als Nebenbemerkung: hätte man die Software auch auf einer UNIX Plattform angeboten, wäre dies möglicherweise bereits früher berücksichtigt worden. Insbesondere, da es nicht nur ein UNIX gibt, sondern diverse, unterschiedliche Versionen, die schon seit Ewigkeiten erforderten, portablen Code zu programmieren.

Das sind Fakten, die man beobachten konnte. Wieso man so was nicht schreiben darf, ohne persönlich beleidigt und angegriffen zu werden, brauch ich nicht verstehen. Solche Reaktionen gibt es normalerweise da, wo man unliebsame, andere Meinungen nicht hören will und deshalb mit Angriffen gegen die Person versucht, aus der Welt zu schaffen.

So und damit basta. Ich habs nicht nötig, mich hier beleidigen zu lassen. EOT.

Wenn Du C kennst, dann kennst Du den Datentyp "int" und dann weißt Du, dass die Verwendung dessen und bestimmte Annahmen über die Größe in Bytes höchst plattformabhängig ist. Deswegen ist es besser, eigene klare Typen zu definieren, die man so verwendet, dass sie auf allen Plattformen gleich funktionieren, statt direkt "int" zu verwenden. Sonst hat man eben größere Schwierigkeiten, wenn man eine Anwendung auf eine Plattform portieren möchte. Oder sogar, wenn man einen Umstieg macht, z.B. von einer 16 Bit zu einer 32 Bit Architektur. Ich hätte gedacht, dass man das als "aktiver Programmierer", der C kennt, wüsste...

Bei Microsoft war auf allen 16 Bit Plattformen sizeof(int)=2. Erst seit dem kompletten Umstieg auf 32bit, d.h. mit XP im Massenmarkt, wurden 4 Byte draus. So lange ist das noch gar nicht her.

Ein anderes Beispiel sind die I/O Funktionen, wo die Datentypen auch eine Rolle spielen. Gut, inzwischen läuft das meiste auf Intel, weshalb die Big/Little Endian keine so große Rolle mehr spielt. Aber früher musste man sich, wenn man Daten in schreiben möchte, die später auf unterschiedlichen Plattformen wieder gelesen werden können, durchaus Gedanken darüber machen, wie man die Daten exakt schreibt und wie diese dann in der Datei dargestellt sind. Der bisschen Hirnschmalz, der dort hineingeflossen ist, dürfte meines Erachtens der Qualität nicht abträglich gewesen sein.

Dies waren Beispiele. Ich behaupte nicht, dass dies auf Buhl Software zutrifft. Es sind nur ein paar der größeren Probleme die einem begegnen, wenn man versucht, z.B. in C geschriebene Windows Software auf eine andere Plattform zu portieren. Da geht es doch immer wieder mal in die tiefsten Tiefen des Systems, weil eben doch so manche Standard-C-Funktion nicht komplett plattformunabhängig ist. Ich weiß, dass dort, wo sehr nah an Windows implementiert wurde, eine spätere Portierung auf eine andere Plattform nur mit extrem großem Aufwand möglich ist, weil oft eben nicht nur die Komponenten zum UI geändert werden müssen. Viele Portierungen wurden deshalb gar nicht unternommen (zu viel Aufwand und Windows ist sowieso dominant) oder die Portierung wurde erst in Angriff genommen, als man wegen schlecht gewucherter Codebasis sowieso mal eine komplette Neuimplementierung machen wollte.

Nochmals: ich behaupte nicht, dass dies auf Buhl Software zutreffen müsste. Was ich oben schrieb, sind Beobachtungen von Projekten. Plattformportierung ist eben oft sehr schwierig, wenn man dies nicht schon von Anfang an mit berücksichtigt hatte.

Ich vermute jedoch, wenn ich mich eben erinnere, welche Schwierigkeiten Buhl z.B. hatte, auf XP Sparbuch auch für eingeschränkte Benutzer ohne manuelle Eingriffe benutzbar zu machen, (z.B. Dateien jederzeit in Programme schreiben zu müssen oder den PDF Drucker beim Start und Ende jedes Mal installieren/deinstallieren zu müssen, was eben nur als Administrator möglich war) das eine Portierung auf eine andere Plattform nicht leicht fallen wird. Diese Schwierigkeiten sind für mich ein Indiz dafür, das bei der Entwicklung (bis zu dem damaligen Zeitpunkt), oftmals eben viel zu nahe an der Plattform und deren Möglichkeiten klebte.

Klar, selbst zu Zeiten von XP war sicherlich noch ein Großteil der Buhl Kunden immer als Administrator angemeldet, weshalb es keine Rolle spielte, dass das primitive Benutzermodell von DOS-WIndows immer noch als Annahme auch für die auf XP lauffähige Version benutzt wurde. Das es ein paar Jahre dauerte und mehrere Versuche, bis z.B. die Dateitrennung halbwegs korrekt durchgeführt wurde, sind für mich wiederum Indizien, dass es am grundlegenden Design irgendwo haperte. Denn eigentlich sollte es doch relativ einfach zu ändern sein, welche Datei von der Software an welche Stelle gelegt und geschrieben wird. Wieso dass dann drei oder vier Jahre dauerte, weiß ich natürlich nicht. Das genannte, ist eine Vermutung von mir. Es ist natürlich möglich, dass das ganz andere Gründe hatte, z.B. dass ein paar der wichtigsten Entwickler zu diesem Zeitpunkt von Buhl weggegangen sind.

Ich vermute, dass eine Software, die mit solchen Umstellungen innerhalb von Windows schon Schwierigkeiten hatte, eben noch viel mehr Probleme kriegen würden, wenn eine Portierung z.B. auf den MAC wirklich in Betracht gezogen werden würde. Und ich nehme mal an, dass Buhl es sich nicht so wie Microsoft leisten kann, einfach ein komplettes anderes Team für die Entwicklung von Office auf Mac zu haben, wo (wenn ich mich nicht irre) im Prinzip so gut wie keine gemeinsame Codebasis zwischen Office-Mac und Office-Windows gibt und deshalb beide Produkte sehr unterschiedlich sind (waren).

So habe ich eben meine Zweifel, dass Buhl wirklich ernsthaft in Betracht ziehen wird, auch andere Plattformen zu unterstützen, zumindest nicht auf einer gewachsenen, Windows-orientierten Codebasis. Aber ich lasse mich gerne positiv überraschen. Eine bestimmten Marktanteil als einzigen Grund anzuführen, ist eben so wie immer fragwürdig. Schließlich wird sich ein Marktanteil nicht ändern, wenn man sich nicht bewegt. Je mehr Software es für den Mac gäbe, desto interessanter wäre auch die Plattform. Und es gibt genügend Beispiele für Software, die auf unterschiedlichen Plattformen läuft...

Sorry, aber DAS ist wohl nicht der Sinn des Forums, und...es gibt leider immer noch sehr viele Anwender, die versuchen mit Win200 zu arbeiten, also lasst doch erstmal diese Menschen nachrüsten, bevor die Software für den Anwender, der nicht tagtäglich damit arbeitet, irgendwie angepasst und für IT-Freaks umgestellt wird. WISO Software soll für alle Normalnutzer händelbar sein, die im Alltag etwas Erleichterung für Finanz und Steueranliegen suchen, oder? Von daher ist eine 32 oder 64 bit, oder WIN und/oder MACDiskussion eher zweitrangig

Schönes WE Euch