Als ich das serielle GLTerm auf GP(IO) 20&21 ( OPTION SERIAL CONSOLE GP20, GP21 )
neu compilieren wollte, ging dies nicht mehr - da FabGL seit dem letzten Compile vor 10 Monaten einige Befehle in andere Classes verschoben hat (Terminal. -> SerialPort.)
So musste ich mir das aktuelle ANSI-Terminal Example vornehmen um die Aenderungen zu finden 
Hat aber nach ein paar Versuchen geklappt 
Gleichzeitig habe ich mal die aktuellste Beta v5.07.05b18 vom Picomite installiert.
Ich habe mir mal die kleine Kurzanleitung "Python - kurz und gut" besorgt. Die ist für vieles schonmal sehr hilfreich, setzt aber voraus, daß man schonmal was anderes benutzt hat. Als absolute Beginner Text taugt das so gar nicht.
In "Python - kurz und gut" habe ich mal bei einer Vorschau reingesehen - und wie Du schreibst ist dies nicht fuer mich als Beginner 
Aber - da sehen wir, dass Dein PRINT noch 2.x Syntax ist und die runden Klammern bei 3.x dazu gekommen ist:
o'Reilly hat aber auch einen ca. 1600 Seiten dicken Klopper "Learning Python" , da werden dann auch mal einige Beispiele zu den Befehlen gezeigt - und dies sogar im Vergleich x2.x und v3.x
Vielleicht solltest Du Dir einfach ein gutes Buch holen ?
Im Anhang mal was zum Reinschauen. Gibt da aber auch Anderes und Übersichtlicheres. Python for Dummies oder sowas aus einem "richtigen" Verlag.
Das habe ich vorher schon mal getan - allerdings sind viele Buecher (auch fuer Anfaenger beschriebene) doch weit ueber dem, was wir frueher an BASIC-Buechern hatten - leider auch bei der Wortwahl und den Zielen.
Deshalb fand ich den YT-3.5-Stunden-Kurs nicht schlecht, dass war im wahrsten Sinne die "BASICs"
Als .PDF habe ich 6 Buecher gefunden, die mir vom Stil eher zusagten:
Zitat von ThoralfAsmussenAchso, mach mal ein Upgrade. Das mit den komischen Klammern bei print etc. ist möglicherweise einfach mal geändert worden. Es gibt da bei Python so einen ziemlichen Versionssprung, zwischen ?? und ??, wo die Sprache nochmal bißchen umdefiniert worden ist.
Dein .PDF-Buch nutzt aber auch bei PRINT noch die Klammern.
Ausserdem Upgrade? Meine Thonny-IDE kommt mit python 3.10.6 und aktuell auf python.org ist 3.10.7
Also wohl im gruenen Bereich.
Mit dem grossen Versionsspring meinst Du evtl. vom alten v2.x auf das neue v3.x
Selbst in den Linux/armbian Distributionen haben die nun auf v3.x umgestellt, dehalb kann man meist python nicht mehr mit python aufrufen, denn das war die v2.x - sondern muss nun python3 aufruegen fuer die v3.x
(ausser man setzt sich einen symolic link : ln -s /usr/bin/python3 /usr/bin/python )
Schoen waere, wenn man nachlesen koennte was nun aktuell ist.
Mein v3.x mochte jedenfalls das Komma nicht, dafuer aber ,end="" in der Klammer um das default Ende-Zeichen zu erstetzen.
Gerade, wo doch der Guidol nicht drumherum kommen wird, das auch mal auf einem seiner vielen kleinen Rechnerchen auszumessen.
Das schöne an Python ist dafür aber, daß es eben gefühlt dadurch ein schöner Basic Nachfolger ist; auch wenn das sicher nicht die Absicht war.
Ach - ich glaube bei der .py-Version spare ich mir den Vergleich, da echtes Python nur auf "groesseren" Systemen laeuft und fuer MicoPython gibt es nicht ganz so viel Hardware, dass sich ein Vergleich lohnt
Mit Thonny auf Windows kann man Python noch beim zeichnen des Apfelmaennchens zusehen....starte ich das ganze auf einem kleinen SCB (NanoPi 64) dann ist nach dem laden von python3 das Apfelmaennchen unterhalb einer Sekunde auf dem Bildschirm.
Bis jetzt hatte ich mir Python nur am Rande mal kurz angesehen, weil es mir etwas "komisch" erschien nur durch Einrueckungen Code-Bloecke zu trennen und nicht durch begrenzende End-Anweisungen.
Aber da die Schulen anstatt BASIC oder Turbo Pascal den kleinen Schuelern jetzt eher Python beibringen, wollte ich fuer meinen Sohn wenistens etwas hilfreich sein, wenn er mal fragt.
Die automatische Konvertierung der Variablen kommt mir als BASIC-Programmierer natuerlich zuvor
Gerade so Sachen wie zhz() sind ja eigentlich dann schon bißchen albern. Das print läßt sich ja nun wirklich einfach so reinschreiben in main().
Mußt Du eigentlich diese Typwandlungen wirklich jedesmal machen ? Das sieht irgendwie seltsam aus - und kostet evtl. sogar Zeit. Die ganzen float() Sachen sind gemeint. Python, weiß das doch eh beim Zuweisen. Bei flowerking ist es lustigerweise genau andersherum, da sind sogar die int echte floats.
Im Nachhinein ist es natuerlich ein wenig albern
Es war - mit den Funktionen - ein erster Versuch (nach dem Python-Crashkurs) die GOTOs der BASIC Version nachzubilden/umgehen. Ausserdem war es eine Moeglichkeit das gelernte vom Kurs anzuwenden/ zu nutzen und ein Gefuehl fuer Funktionen zu bekommen, da ich doch eher aus der alten GW-BASIC Ecke komme (und davon einige Sachen bei MBASIC unter CP/M vermisse).
Zum Schluss habe ich dann auch im Code die Inhalte der Funktionen wieder in main() uebernommen.
Die Definition der ganzen floats, war ein Versuch raus zu finden, ob die falsche Ausgabe evtl. daran scheitert, weil ich nicht wusst was Python selbst erkennt oder konvertiert (und es in der .PAS (Turbo Pascal) Version auch definiert wurde - weil man es da eher musste).
Ich würde es so machen:
Danke dass sind die richtigen Buchstaben/Zahlen
Lag wohl am ca=x*0.0458 (bei Dir) und ich hatte woander falsch uebernommen die ca=x*0.0448
def zh(i):
if i > 9:
i = i + 7
else:
i = i
print (chr(48+i), end="")
def zhz():
print ("")
for y in range (-12, 12+1, 1):
for x in range (-39, 39+1, 1):
ca = float(x*0.0458)
cb = float(y*0.08333)
a = float(ca)
b = float(cb)
for i in range (0, 15+1, 1):
powa = float(a*a)
powb = float(b*b)
t = float(a*a-b*b+ca)
b = float(2*a*b+cb)
a = float(t)
z = float(a*a+b*b)
if z > 4:
zh(i)
break
if z <= 4: print (" ", end="")
# next i
#next x
zhz()
# next y probier mal das
Deine print-syntax mag mein Python 3.10.6 irgendwie nicht
Aber mit leichten Anpassungen klappt es
Die Buchstaben/Zahlen kommen nun schon naeher dran, aber sind noch nicht 100% die gleichen.
Sind das evtl. sowas wie Rundungsfehler?
def zh(i):
if i > 9:
ac = i + 7
else:
ac = i
print (chr(48+ac), end="")
def zhz():
print("")
for y in range (-12, 12+1):
for x in range (-39, 39+1):
ca = float(x*0.0448)
cb = float(y*0.08333)
a = ca
b = cb
for i in range (0, 15+1):
t = a*a-b*b+ca
b = 2*a*b+cb
a = t
z = a*a+b*b
if z > 4:
zh(i)
break
if z <= 4: print (" ", end="")
zhz() Von Python habe ich wenig Ahnung, aber in C++ würde ich das ungefähr so machen
flowerking Vielen Dank Das hat schon mal SEHR geholfen!
Die Anzeige / Zahlen / Buchstaben sind zwar noch nicht ganz wie bei der BASIC-Variante,
aber nun laesst sich scon mal was erkennen vom FRACTAL / Mandelbrot:
Hier mein -jetzt- aktueller Paython-Code, nach dem einfuegen Deiner Vorschlaege.
x = float
y = float
a = float
b = float
ca = float
cb = float
powa = float
powb = float
powc = float
t = float
i = int
for y in range (-12, 12+1):
for x in range (-39, 39+1):
ca = x*0.0458
cb = y*0.08333
a = ca
b = cb
for i in range (0, 15+1):
powa = a*a
powb = b*b
powc = a*b
t = powa-powb+ca
b = 2*powc+cb
a = t
z = powa+powb
if z > 4:
break
if i >= 15:
print(" ", end="")
else:
if i > 9:
i = i + 7
print (chr(48+i), end="")
# next i
# next x
print ("")
# next y Da mein 10 aehriger Sohn dies Jahr Python n der Schule gelert bekommt, habe ich mir mal folgendes 3 Stunden Einfuehrungsvideo angesehen.
Ermutigt durch die ersten Erfolge dachte ich, dass ich das Mandelbrot FRACTAL.BAS umsetzen koennte - es ist ja nicht so lang.
Nur komme ich mit den GOTOs und Schleifen unter Python ins straucheln
Kann da evtl. mal ein Python-kundiger draufschauen, wo mein "Knoten" in den Gedanken ist?
Bei der Ausgabe wird einfach nur der ASCII-Wert raufgezaehlt und die Zeile ist viel zu lang (beim .BAS unter 80 Zeichen)
Also hier das .BAS
10 FOR Y=-12 TO 12
20 FOR X=-39 TO 39
30 CA=X*.0458
40 CB= Y*.08333
50 A=CA
60 B=CB
70 FOR I=0 TO 15
80 T=A*A-B*B+CA
90 B=2*A*B+CB
100 A=T
110 IF (A*A+B*B)>4 THEN GOTO 200
120 NEXT I
130 PRINT " ";
140 GOTO 210
199 REM ZH
200 IF I>9 THEN I=I+7
205 PRINT CHR$(48+I);
210 NEXT X
219 REM ZHZ
220 PRINT
230 NEXT Yund mein klaeglicher Python-Versuch aus der Windows-Thonny-IDE:
def zh(i):
if i > 9:
ac = i + 7
else:
ac = i
print (chr(48+ac), end="")
def zhz():
print ("")
for y in range (-12, 12+1):
for x in range (-39, 39+1):
ca = float(x*0.0448)
cb = float(y*0.08333)
a = ca
b = cb
for i in range (0, 15+1):
t = float(a*a-b*b+ca)
b = float(2*a*b+cb)
a = float(t)
z = float(a*a+b*b)
if z > 4:
zh(i)
# next i
#next x
zhz()
# next y Was meinst Du mit 15KHz - welche Bildquelle soll die liefern ? Der Monitor hat nur einen VGA- und einen DVI-Eingang...
Evtl. ein AMIGA 
Der Pico emuliert einen Arduino und auf dem Arduino läuft dann RunCPM?
Nicht ganz
Durch den arduino-pico bekommt der Pico sozusagen eine Befehls-API wie ein Arduino,
d.h. die Arduino Befehle werden auf die entsprechenden des Pico gemappt.
Es wird keine Rechenzeit fuer eine Arduino-Emulation genutzt/verschwendet.
ZitatRaspberry Pi Pico Arduino core, for all RP2040 boards
This is a port of the RP2040 (Raspberry Pi Pico processor) to the Arduino ecosystem.
It uses the bare Raspberry Pi Pico SDK and a custom GCC 10.3/Newlib 4.0 toolchain.
In Defender -Virendefition von heute ist wohl ein Fehler, deshalb meldet Windows schon den ganzen Tag
Microsoft untersucht es und wird einen Patch bereitstellen.
Sogar wenn man einfach nur die PC-Einstellungen oeffnet - nachschauen kann man nicht woher, denn die meldung wird gleich wieder geloescht.
Einzig die Bild konnte ich einfangen:
RunCPM Pico Update auf RP2040 arduino-core v2.5.2
Mit den cpmtools von kkaempf funktioniert jetzt auch Schreiben auf Drive C.
weiss man, was das geaendert wurde dass es nun klappt - oder ist es evtl. nur eine angepasste diskdefs?
Ein 900Mhz Celeron eeePC 701/4G scheint mit dem -O3 RunCPM fuer DOS fast genauso schnell wie der 1.6GHz Atom...
DOS wurde ueber eine SD Karte gebootet.
Die Karte habe ich mit dem DELL FX160 erstellt (Drive 2 in FDISK) aber die Boot-Partition konnte ich nur im Linux FDISK aktivieren, da DOS dies sonst nur auf Platte 1 macht...
In der DOSBox-X ist RunCPMO3 langsamer als auf meinem 1.6GHz ATOM
obwohl die DOSBox-X auf einem AMD Phenom II X4 mit 3GHz laeuft
In der Config-Datei braucht es ein ansi=false
damit man den NNANSI nachladen kann, denn der DOXBox-X ANSI ist auch nicht besser als der vom MS-DOS
Es gibt doch nochmal Geschwindigkeitsunterschiede wenn man RunCPM fuer DOS mit verschiedenen Optimierungs-Optionen compiliert.
Bis jetzt waren RunCPMFB und RunCPMPB mit der Option -O0 compiliert (reduzierte Zeit fuer die Compilierung)
und das ergibt 368KB
Die Zeiten sehen aber schon ganz anders aus bei den Optionen
-Os (Optimierung auf Binary-Size) - mit 423KB allerdings immer noch groesser als bei -O0
-O3 (Optimierung auf Geschwindigkeit) - mit 560KB der groesste Brocken
Die Versionen mit fput oder putchard geben sich bei den Optionen nicht mehr im Speed, deshalb bleibt beim compilieren einfach bei der fput-Variante
Auf einem DELL FX160 (1.6GHz ATOM)
unter MS-DOS 6.22 mit NNANSI 5/93 und CWSDPMI als Extender
Zum Vergleich FRACTAL gegen sich selbst auf dem FX160 mit den verschiedenen Optimierungs-Optionen beim compilieren:
- Option -O0 (Minimierung der Compile-Zeit)
FRACTAL.BAS interpretiert 18 Sekunden
FRACTAL.BAS compiliert 12 Sekunden
- Option -Os (optimiert auf Binary Size - ist aber doch groesser als -O0)
FRACTAL.BAS interpretiert 6 Sekunden
FRACTAL.BAS compiliert 4 Sekunden
- Option -O3 (auf Speed optimiert)
FRACTAL.BAS interpretiert 4 Sekunden
FRACTAL.BAS compiliert 4 Sekunden
Spannend finde ich, dass bei -O3 sich die Zeitspanne zwischen interpretierter und
compilierter Version (handgemessen) nicht mehr unterscheidet
Richtig, die CPC Version hat einige Anpassungen ans System…
Außerdem fehlt sie noch im Regal😉
xesrjb Nicht fuers Regal, aber fuer die Platte/Diskette:
Turbo Pascal CPC GX 128K 6128 (UK)
Nach einem kleinen Captcha startet der Download
Lese ich erst jetzt ... TESTTERM ist doch ein CP/M- Programm, nix DOS
Stimmt ja
TESTTERM im VT100-Mode klappt einwandfrei mit NNANSI und RunCPM fuer DOS
Welches genau: fputc für "character" oder fputs für "string"?
Ist ja auch richtig so.
fputc für "character" weil in der console.h dann folgt:
void _putcon(uint8 ch) // Puts a character
{
_putch(ch & mask8bit);
}
void _puts(const char* str) // Puts a \0 terminated string
{
while (*str)
_putcon(*(str++));
}denn in der abstract.h habe ich:
void _putch(uint8 ch) {
fputc(ch,stdout);
// putchar(ch);
}d.h es baut so auf: fputc -> _putch -> _putcon -> _puts
Somit denke ich, dass alles fput (oder putchar ist - wenn man es umstellt)
Veroeffentlicht ist der Source noch nicht, weil noch keiner fragte
(OK - fuer Binary hat auch noch keiner gefragt...)
Anbei der derzeitige Source
Nur etwas Erfahrung mit einem anderen Emulator, der ebenfalls in "C" geschrieben ist ...
Eigentlich - da alle Ausgabe-Definitionen aufeinander aufbauen sollte RUNCPMFB nur mit fput laufen
(denk ich) - ist ja nicht wirklich "mein" Code. Ich pass den an und nenne es Fork/Port
setvbuf(stdout, NULL); sollte diese "Bufferung" für die Ausgabe ganz abschalten ... wird dann natürlich auch langsamer ...
JenGun
WOW wie hast Du dies so schnell gefunden? Kannst den Source schon auswendig?
Ich kann sagen, dass es das war! PRIMA!!
Ich habe mit dieser Einstellung nun
- RUNCPMFB (fput ohne Buffer)
- RUNCPMPB (putchar ohne Buffer)
compiliert und nun wird beim FRACTAL.BAS auch wieder alles nach einem Zeichen ausgegeben
Bei meinem 1.6GHz Atom (DELL FX160) faellt der Geschwindigkeitsverlust bei der Ausgabe nicht auf.
Der NNANSI scheint bei der Ausgabe etwas zu buffern, da beim durchlaufen des FRACTSL.BAS (egal ob interpretiert oder schon compiliert) die Ausgabe nur nach der kompletten Zeile kommt.
Evtl. teste ich es nachher nochmal mit dem VT52.SYS und ganz ohne ANSI.
Interessant Nach der Umstellung auf fput/putchar die FRACTAL.BAS Ausgabe ist auch ohne ANSI-Driver auch "nur" nach jeder berechneten Zeile
Also liegt es nicht an NANSI.COM/VT52.SYS
In Worstar und dem Turbo Pascal Menue faellt es nicht auf und ein MBASIC-Listing wird zu schnell angezeigt, dass es auffaellt.
DANKE an alle (in alphabetischer Reihenfolge) die mich unterstuetzt haben, die RunCPM-Bildschirmausgabe unter DOS zum laufen zu bekommen
JenGun
Danke fuer die Infos zu putchar und standard output
Dies hat zusammen mit der Infos zu fput von Martin Hepperle mir das Verstaendnis naeher gebracht,
dass stdio nicht ein File sein muss
Martin Hepperle
Danke fuer die Infos zu fputs
und fuer ein CLS bei ANSI wurde ein print("\e[H\e[J"); langen.
Peter z80.eu
Danke fuer den Tipp zur Ausgabe per DOS-Interrupt
Dadurch fand ich heraus, das DJGPP bei putc BIOS-Interrupts nutzt.
Der NNANSI scheint bei der Ausgabe etwas zu buffern, da beim durchlaufen des FRACTSL.BAS (egal ob interpretiert oder schon compiliert) die Ausgabe nur nach der kompletten Zeile kommt.
Evtl. teste ich es nachher nochmal mit dem VT52.SYS und ganz ohne ANSI.
Aufrufe von system(s) sollte man nur verwenden, wenn Programme gestartet werden sollen, für ein "clear screen" ist das ziemlich unwirtschaftlich.
Es wird dabei ja jedes Mal ein kompletter Prozess gestartet und damit ist ohne Rechtsanwalt nicht zu spaßen.
Wenn man schon ANSI Sequenzen verwendet ist es besser das auch mit einer Escape-Sequenz zu erledigen.
Habe ich mir nochmal durch den Kopf gehen lassen
1. es wird nur begrenzt genutzt (nicht aus Programmen heraus die eh ANSI-Sequenzen nutzen) sondern nur beim CLS an der Commandline und im RunCPM-Source der abgekapselt von den Programmen ist.
2. bei diesen wenigen Zugriffen loescht es den Bildschirm unabhaengig von der genutzten Bildschirm-Emulation (also ANSI, VT52, ADM, Kaypro)
Unter DOS gibt es kaum alternative Display-Driver (die ich kenne) aussder ANSI und nun VT52.
Klar, wenn man sich auf ANSI festlegt, koennte man auch einen ANSI ClearScreen Code senden und haette es eleganter erledigt
Aber wie geschrieben, tritt die Nutzung nicht innerhalb der CP/M Programme zu.
Zum Testen der ANSI Sequenzen kannst Du auch http://www.z80.eu/downloads/TESTTERM101.ZIP bemühen, das habe ich ja mal extra für's Ausprobieren diverser Terminalemulationen geschrieben.
P.S.: Statt VT100 via ANSI.SYS kannst Du auch VT52 testen, und zwar mit dem angehängten DOS-Gerätetreiber VT52.SYS (im ZIP).
Leider verweigert sich mein DOS-Rechner dem TESTTERM - wenn ich es lade bleibt er am Eingabeprompt haengen
Der VT52.SYS geht "soweit" - d.h. wenn man Wordstar auf VT52 umkonfiguriert (per WINSTALL) dann klappt die Bildschirmausgabe, allerdings fehlt dann das Attribut der Hervorhebung fuer die Menue-Punkte
- ANSI ESC 1m fuer BRIGHT
- ANSI ESC 0m fuer NORMAL
aber immerhin besser in der Funktion als der ANSI.SYS und ANSI.COM/MYANSI.COM
Der Vorteil beim NNANSI.COM ist dass er nachtraeglich (wenn gebraucht) geladen werden kann (NNANSI D) und nach Gebrauch auch wieder entladen werden kann (auch wenns nur ca. 4Kb sind).
Im angehaengten Archiv sind 2 RunCPM-Versionen
- RUNCPMFP.EXE fuer fput
- RUNCPMPC.EXE fuer putchar
Die beiden scheinen sich aber nichts zu geben
Zusaetzlich ist der CWSDPMI.EXE Extender dabei und NNANSI.COM in der v1.93
Leider erkennt man die Helligkeitsunterschiede fuer die Menues auf den Fotos kaum, aber am Bildschirm erkennt man es ganz klar.
MOMENT !!
mit dem fput hatte ich nur unter der Win7 Eingabeaufforderung getestet
Jetzt habe ich es nochmal auf meinem DOS-Rechner (DELL FX160 mit MSDOS 6.22) getestet,
weil es stand ja im Internet die DOS-Interruts laufen auch nur unter echtem DOS (d.h. ich hatte zwar unter Win7 es mit ANSICON probiert - half da aber nichts)
Der erste Versuch mit dem original ANSI.SYS in der CONFIG.SYS erwies sich als Anfang, denn Wordstar loeschte den Bildschirm, zeigte das Menue an....loeschte es ABER DANN WIDER
Im leeren Bildschirm konnte man dann die Menue-Punkte zwar aufrufen, aber spaetestens im WS-Editor klappt das scrollen und Cursor-navigieren nicht.
Erste Gegentests mit Alternativen ANSI wie ANSI.COM oder MYANSI.COM ergaben leider nur das selbe.
ABER ich hatte nch einen 3ten Trumpf NNANSI.COM (v1.93) - den geladen (aus dem Gedaechtnis erstmal als NNANSI D - da sollte er mehr Moeglichkeiten haben und spaeter auch nur mit NNANSI fuer die "einfache" Variante)
Und was soll ich sagen Wordstar wird sauber angezeigt, scrollt, Cursor klappt
#define _putch(c) fputc(c,stdout)
#define _puts(s) fputs(s,stdout)
Das _putch habe ich in der abtract.h wie folgt definiert
void _putch(uint8 ch) {
// putchar(ch);
fputc(ch,stdout);
}putchar/fputc brachte leider bei der Ausgabe keinen Unterschied
In der globals.h habe ich
// extern void _puts(const char* str);
#define _puts(s) fputs(s,stdout);eingetragen, aber das brachte leider nur folgenden Fehler beim compilieren:
c:\DJGPP\HOMECH>make dos build
"Platform = dos (type 'make all' for help)"
c:/djgpp/bin/make.exe -f Makefile.dos all
make[1]: Entering directory 'c:/djgpp/homech'
gcc.exe -Wall -O0 -Wno-pointer-sign -g -c main.c
In file included from abstract.h:4,
from main.c:33:
globals.h:232:27: error: expected declaration specifiers or '...' before '(' token
232 | #define _puts(s) fputs(s,stdout);
| ^~~~~~
console.h:28:6: note: in expansion of macro '_puts'
28 | void _puts(const char* str) // Puts a \0 terminated string
| ^~~~~
In file included from main.c:49:
console.h:29:1: error: expected identifier or '(' before '{' token
29 | {
| ^
make[1]: *** [Makefile.dos:34: main.o] Error 1
make[1]: Leaving directory 'c:/djgpp/homech'
make: *** [Makefile:19: build] Error 2In der console.h gibt es noch
void _putcon(uint8 ch) // Puts a character
{
_putch(ch & mask8bit);
}
void _puts(const char* str) // Puts a \0 terminated string
{
while (*str)
_putcon(*(str++));
}aber die Befehle bauen auf der abtract.h auf wegen dem fuehrenden _ (Unterstrich)
Irgendwo frage ich mich, ob ESC richtig umgegesetzt wird mit dem Pfeil nach LINKS,
nicht da es da haengt und wir/ich falsch suche. Bei der Linux Version klappt die Umsetzung.
