Beiträge von Jens-Arne

Ja, stimmt. Aber in meiner DLL ist das alles ein bisschen komplizierter, z.B. weil es bekannte AMD-Bugs gibt, bei denen der Zufallsgenerator nur nullen oder einsen zurückgibt, also völlig defekt ist. Im englischen PureBasic-Forum in der Windows-Abteilung ist der Quellcode zu finden, falls es jemanden interessiert.

Hallo,

ich habe eine DLL geschrieben, die die auf modernen Prozessoren hardwaregenerierten echten Zufallszahlen anzapft. Sie werden aus thermischem Rauschen eines speziellen Chips erzeugt. Zusätzlich gibt es einige weitere Funktionen wie z.B. eine für die automatische Erstellung sicherer Passwörter aus diesen Zufallszahlen. Es sind eine PDF-Anleitung sowie ein rudimentäres XProfan-Beispiel beigefügt. 32bit- (z.B. XProfan) und 64bit-Variante vorhanden.

Der Inhalt kann nicht angezeigt werden, da Sie keine Berechtigung haben, diesen Inhalt zu sehen.

Gruß, Jens-Arne

Guten Morgen, hier die Antwort von Prof. Gemini:

Läuft auf modernen Windows-Tablets ganz normal Windows 11? D.h. kann man z.B. mit XProfan erzeugte Programme darauf laufen lassen und den Touchscreen wie Mausklicks abfragen?

Ja, auf modernen Windows-Tablets läuft das ganz normale Windows 11.

Hier sind die wichtigsten Details zu Kompatibilität und Touch-Bedienung für Ihre Entwicklung:

Windows 11 auf Tablets

• Volles Betriebssystem: Es handelt sich nicht um ein abgespecktes Mobil-System (wie damals Windows RT).
• Architekturen: Es gibt Intel/AMD-Tablets (x64) und zunehmend ARM-Tablets (wie das Surface Pro 11).
• XProfan-Kompatibilität:
  • Auf Intel/AMD-Tablets laufen Ihre XProfan-Programme direkt.
  • Auf ARM-Tablets laufen XProfan-Programme dank der integrierten Windows-Emulation in der Regel ebenfalls problemlos.

Touchscreen als Mausklick abfragen

Windows übersetzt Touch-Eingaben standardmäßig so, dass sie für herkömmliche Software funktionieren:

• Einfaches Tippen: Wird vom System automatisch als linker Mausklick an Ihr Programm übergeben.
• Gedrückthalten: Wird von Windows als rechter Mausklick interpretiert.
• Standard-GUI: Normale XProfan-Controls (Buttons etc.) lassen sich ohne Code-Änderung per Touch bedienen.

Praxistipps für Tablets

• Button-Größe: Standard-Buttons sind oft zu klein für Finger. Erhöhen Sie die Breite und Höhe der Steuerelemente.
• Abstände: Lassen Sie mehr Platz zwischen anklickbaren Elementen, um Fehlklicks zu vermeiden.
• Native Touch-Gesten: Wenn Sie komplexe Gesten (wie Pinch-to-Zoom oder Wischen) auswerten möchten, müssen Sie über die Windows-API (RegisterTouchWindow_() etc.) tiefer in die Ereignisverarbeitung einsteigen.

Ist XProfan.com eigentlich dauerhaft kaputt? Da ist immer noch ziemlich viel nicht erreichbar, auch wenn die Seite auf den ersten Blick ok aussieht. Dann hätten wir jetzt überhaupt keinen Ort mehr, wo man Code vernünftig teilen kann... Hier kann man Posts ja leider nicht mehr ändern und damit auch keine neuen Versionen zur Verfügung stellen.

Guten Abend zusammen,

klar kann ich das hier hochladen: Der Inhalt kann nicht angezeigt werden, da Sie keine Berechtigung haben, diesen Inhalt zu sehen.

Das Problem ist nur, dass man hier ja nichts aktualisieren kann. Diese Version bleibt hier also eingefroren, es sei denn, ich lade das immer wieder neu in einem eigenen Posting hoch. Ich habe jetzt aber auch schon länger nichts mehr daran geändert.

Und xprofan.net scheint auch wieder zu funktionieren, wie es aussieht.

Beste Grüße, Jens-Arne

Das ist ja wirklich ein Ding. In der Tat liefert @addr(s$) 0 zurück, wenn s$ noch kein Wert zugewiesen wurde. Wenn man aber print s$ benutzt, stürzt nichts ab. XProfan scheint "Adresse=0" als Leerstring zu interpretieren. Ich dachte immer, ein String, dem noch nichts zugewiesen wurde, wäre ein gültiger Leerstring, der auch eine entsprechende Speicheradresse hat. Böse Falle!

Wow. Es wird noch schlimmer! Jeder Leerstring hat in XProfan die Speicheradresse 0, auch wenn der Stringvariablen vorher schon etwas zugewiesen wurde! Beispiel:

cls
declare s$
s$="1"
print @addr(s$) 'ist eine gültige Speicheradresse
s$=""
print @addr(s$) 'ist =0 !
waitinput

Ich habe gerade mal nachgesehen, wie das andere Programmiersprachen machen.
In PureBasic hat eine Stringvariable, der noch nie ein Wert zugewiesen wurde, auch die Adresse 0.
Wenn man einen String zuweist, bekommt man (erwartungsgemäß) eine gültige Adresse.
Wenn man danach wieder "" zuweist, bleibt die Adresse gültig. Das ist in XProfan anders.

Wenn man in PureBasic einer Stringvariablen nur einmal "" zuweist, bekommt man sofort eine gültige Adresse.
Wenn man XProfan einer Stringvariablen, die schon einmal etwas <>"" enthalten hat, per string @addr(s$),0="" einen Leerstring zuweist, bleibt die Adresse erhalten. Wenn man das mit einer noch nie benutzten Stringvariablen versucht, stürzt das Programm ab. Offenbar ist der Workaround mit einer Stringvariablen, die man künstlich mit Leerzeichen füllt, ziemlich gefährlich. Wenn die an irgendeiner Stelle mal ="" wird, gibt es sofort einen Absturz, wenn man das als Bereich benutzt - natürlich auch, wenn die Länge kleiner wird, als das, was man da reinschreiben will. Wenn man hingegen gleich eine Bereichsvariable benutzt, kann einem nichts passieren, weil man deren Größe voll in der Hand hat.

Hallo,

so geht's:

UsePNGImageDecoder() 
OpenWindow(0, 0, 0, 500, 550, "Frohe Ostern",#PB_Window_SystemMenu | #PB_Window_ScreenCentered)
If LoadImage(1, "Rahmen.png", 0) And LoadImage(2, "Nest.png", 0)
  LoadFont(1,"Arial", 18, #PB_Font_Bold )
  ResizeImage(1, 480, 530)
  ResizeImage(2, 320, 320)
  ImageGadget(0,  5, 5, 480, 530, ImageID(1))                  
  ImageGadget(1, 80, 110, 320, 320, ImageID(2)) 
  StartDrawing(WindowOutput(0))
    DrawingMode(#PB_2DDrawing_Transparent)
    DrawingFont(FontID(1)) 
    DrawText(146, 75, "FROHE OSTERN!",RGB(13, 27, 186)) 
  StopDrawing() 
EndIf  
Repeat : Until WaitWindowEvent() = #PB_Event_CloseWindow
FreeImage(1)
FreeImage(2)
End

Außerdem wäre DrawImage statt ImageGadget wahrscheinlich etwas direkter, aber so funktioniert es ja.

Hallo zusammen,

mir ist gerade etwas Verblüffendes aufgefallen: Im folgenden Listing ist der Zugriff auf einen Long-Speicherbereich sowohl interpretiert als auch kompiliert etwa doppelt so schnell, wenn man ihn über eine Struktur-Bereichsvariable vornimmt, als wenn man den Kassiker (long) benutzt. Die direkte Zuweisung ist allerdings immer noch am schnellsten, aber das geht manchmal nicht, weil man direkt an eine Speicherstelle schreiben muss, die nicht als einfache Variable definiert ist.

STRUCT S_FastL=l&

declare FastL#,aOldFastL&,i%,tc&,l&

cls
dim FastL#,S_FastL
aOldFastL&=FastL#
FastL#=@addr(l&)

tc&=&GetTickCount
for i%,1,100000
  l&=0
endfor 'i%
print "direkte Zuweisung: "+@str$(&GetTickCount-tc&)+"ms"

tc&=&GetTickCount
for i%,1,100000
  long FastL#,0=0
endfor 'i%
print "Poke: "+@str$(&GetTickCount-tc&)+"ms"

tc&=&GetTickCount
for i%,1,100000
  FastL#.l&=0
endfor 'i%
print "Strukturvariable: "+@str$(&GetTickCount-tc&)+"ms"

waitinput
FastL#=aOldFastL&
dispose FastL#
end

Woran das wohl liegt? Das kann bei einer Schleife mit sehr vielen Speicherbereichszugriffen ja schonmal einen riesigen Unterschied ausmachen.

Puh, das ist eine gute Frage. Offenbar merkt sich XProfan die Einstellungen nach dem letzten StartPaint. Anders kann ich mir das nicht erklären. Und ja, die beiden Fenster haben verschiedene DCs, das geht gar nicht anders. Vielleicht nutzt XProfan intern einen einzigen "unsichtbaren" DC für StartPaint-Operationen und kopiert den Inhalt dann immer in den Ziel-DC. Das kann nur Roland beantworten.

Stimmt, das sollte in der Hilfe stehen. Ist aber eigentlich auch klar, weil StartPaint ja für alle Grafikfunktionen einen anderen DC setzt, und in dem ist die neue Schriftart noch nicht eingebunden (Windows-API: SelectObject).

Ich habe jetzt so ziemlich alles durchprobiert, was möglich ist (E-Cores abgeschaltet, DDR5-RAM Latency untersucht, Kernisolierung abgeschaltet, hohe Prozessorpriorität gewählt, auf Core 0 beschränkt, und, und, und). Nichts hat irgendetwas verändert. Es scheint darauf hinauszulaufen, dass die Branch Prediction der 14. Generation Intel-Prozessoren (Raptor Lake Refresh) das Problem ist. Der Interpreter springt ständig durch seine SELECT-Liste, welches Token wohin verzweigen soll. Das kann der Prozessor nicht sinnvoll vorhersagen und muss deshalb jedesmal die ganze Prediction-Pipeline verwerfen, die bei diesen Prozessoren sehr tief ist. Das scheint beim i7-14700K extreme Performanceeinbußen zu bewirken. Die 12. Generation (Alder Lake) funktioniert noch super, ich habe einen i7-1280P in einem Mini-PC, der mit XProfan superschnell ist. Ob die 13. Generation geht, weiß ich nicht. Wenn Ihr also im Betrieb die Hardware erneuern wollt, sollte man das beachten. Vielleicht geht es mit AMD besser, das weiß ich ebenfalls nicht. Und wenn doch noch jemand eine Idee hat, was ich noch tun könnte, gerne her damit. Aber ich verliere da so langsam die Hoffnung.

Danke Dir! Das meiste davon habe ich schon ausprobiert, soweit sinnvoll - ohne Erfolg. Am meisten merkt man den Performanceeinbruch beim Füllen eines TreeViews mit den einzelnen Datensätzen der Datenbank. Das ging vorher viel schneller, und auf anderen "kleineren" modernen Computern ist es auch viel schneller. Eigentlich kann das dann nichts mit Firebird zu tun haben, weil die Abfrage zu der Zeit schon vorbei ist und das TreeView rein von XProfan mit dem Ergebnis der Datenbankabfrage gefüllt wird. Auf der anderen Seite ist jede Folgeabfrage jetzt irgendwie auch ziemlich langsam, auch wenn nur ein einziger "Hit" in der Datenbank, die natürlich Indizes nutzt, gesucht wird. Das ist alles ziemlich blöd.

Moin Axel,

ich habe das in allen erdenklichen Varianten ausprobiert, aber leider ändert sich durch Defender-Einstellungen nichts daran. Ich bin wirklich ratlos. Andere neue Computer waren und sind beim Ausführen von XProfan-Programmen immer deutlich schneller gewesen als die Vorgänger, aber bei meinem jetzigen High-End-System ist das völlig anders. Ich verstehe das nicht. Das ist allerdings auch die erste Hybrid-CPU, die ich nutze. Aber, wie gesagt, auch das Abschalten der E-Cores hat nichts verändert.

Hallo zusammen,

ich habe mir nach neun Jahren mit einem Intel i7-7700K-Prozessor (32 GB DDR4-RAM) ein neues System mit Intel i7-14700K-Prozessor und 32 GB DDR5-RAM gegönnt. Paradoxerweise laufen die XProfan-Programme damit deutlich langsamer als mit dem alten System, insbesondere bei Datenbanknutzung (Firebird 3). Ich habe schon die E-Cores abgeschaltet, damit Windows die Programme nicht darauf scheduled, daran liegt es nicht. Hat irgendjemand die gleiche Erfahrung gemacht und vielleicht sogar eine Idee, was man dagegen tun kann? DDR5 hat eine höhere Latenz als DDR4, aber ich glaube nicht, dass das so einen deutlichen Effekt hat (50% langsamer als mit dem alten System), wie ich ihn beobachte.

Beste Grüße, Jens-Arne

Moin!

Erste Erkenntnis:
Es funktioniert mit 64bit! Super Arbeit!! Kompilier' das nochmal mit 32bit, es gibt eigentlich keinen Grund, warum das nicht klappen sollte. Und jetzt brauchen wir wirklich mal eine sinnvolle Dokumentation.

Zweite Erkenntnis:
Ich habe JRPC3 offenbar nicht völlig umsonst geschrieben. Du hast versehentlich die *.enh3-Datei mitgeliefert. Das freut mich wirklich extrem! Da steckt so viel Arbeit drin, die nun, da XProfan ja leider dem Untergang geweiht ist, völlig vergeblich zu sein schien - war sie aber vielleicht ja doch nicht ganz.

Herzliche Grüße, Jens-Arne

Danke! Gleich geht's los, muss mich auf den Weg machen.

Guten Morgen, ich muss gleich nach Stuttgart fliegen und bin deshalb beim 1. Kaffee.

Ich habe es mit PureBasic 64bit getestet, da ist es dasselbe: Absturz, nachdem die Seite geladen wurde. Und zwar leider ohne spezifische Fehlermeldung, was für einen Fehler in der DLL spricht.

Ich meinte oben: Ist g_host in der C++-DLL als 64bit-Pointer deklariert? Sonst geht die Message irgendwohin, weil die oberen 32bit des Pointers abgeschnitten werden.

Allerdings wird a sofort gelöscht, wenn das PostMessage raus ist. Das Hauptprogramm versucht dann, daraus die neue URL zu lesen, also aus einem nicht mehr existierenden Pointer auf den Text der URL. Das kann klappen, muss es aber nicht - auch in 32bit dürfte das dann und wann einen undefinierten Absturz provozieren. a muss daher global deklariert werden und persistent sein. Das dürfte das Problem sein.

Noch eine Frage: Warum muss man mit einer Schleife versuchen, WV_NewTab dazu zu bewegen, einen gültigen Wert für das neue Web-Control zu erhalten? Wenn noch nicht alles initialisiert ist, sollte WV_Init so lange mit dem Return warten, bis alles bereit ist.

SetTimer 10
While t[0] = 0
 WaitInput
 t[0] = WV_NewTab()
EndWhile
KillTimer

Ist g_host auf 64bit-Pointer gecasted bzw. so definiert? Der Rest von PostMessage sieht eigentlich ok aus.

Mit einer Hilfe meinte ich eigentlich neben einem natürlich extrem hilfreichen Code-Beispiel eine Beschreibung der Funktionen und insbesondere davon, was deren Parameter machen.

Sieht gut aus! DIe 64bit-Version funktioniert allerdings jedenfalls mit FreeProfan64 nicht: Der Inhalt kann nicht angezeigt werden, da Sie keine Berechtigung haben, diesen Inhalt zu sehen.

Besser kann ich die Fehlermeldung nicht abbilden, das ist ja in FreeProfan64 immer etwas schwierig. Es mag sein, dass es mit PureBasic 64bit geht, aber dafür fehlt mir noch eine aussagekräftige Hilfedatei zu Deiner DLL. Es wäre empfehlenswert, jetzt schon mit deren Erstellung anzufangen, damit es nachher nicht eine so riesige Aufgabe wird.

Es wird beim Start ein Verzeichnis "XProfanBrowser.exe.WebView2" mit diversen Unterverzeichnissen angelegt, die allerdings weitestgehend leer sind (wenn nicht sogar vollständig leer). Was ist das und ist das nötig?

Wow, sehr schön!!

Kannst Du auch eine 64bit-Variante erzeugen, oder geht das mit der Sprache nicht, die Du nutzt?

Kann man den Inhalt des URL-Edit-Controls automatisch an die URL der Seite, die gerade angezeigt wird, anpassen? Vermutlich mit Event-verknüpftem JavaScript? In PureBasic wäre das:

BindWebViewCallback(_nMainScreen,"sendUrlToPB",@OnGetStreamUrl())

Procedure OnGetStreamUrl(JsonParameters$)
  _AktGadgetURLFromFuncGetWebViewGadgetURL$=mid(JsonParameters$,3,len(JsonParameters$)-4)
EndProcedure ;OnGetStreamTime

Procedure.s GetWebViewGadgetURL(nGadget.i)
  protected tc.q
  _AktGadgetURLFromFuncGetWebViewGadgetURL$=""
  WebViewExecuteScript(nGadget,"sendUrlToPB(window.location.href);")
  tc=ElapsedMilliseconds()
  while (_AktGadgetURLFromFuncGetWebViewGadgetURL$="") and (ElapsedMilliseconds()-tc<500)
    while WindowEvent()
    wend
  wend
  ProcedureReturn _AktGadgetURLFromFuncGetWebViewGadgetURL$
EndProcedure ;GetWebViewGadgetURL

Beste Grüße, Jens-Arne