Beiträge von Andy

Hi,

in der aktuellen c´t lese ich gerade einen Artikel, der sich mit "Programmiersprachen" beschäftigt, auch wird die Anfängerfreundlichkeit nachgefragt.

Auch online erhältlich https://www.heise.de/ct/artike…ereinsteiger-4769771.html

Ich habe mir, mit meiner mittlerweile fast 45-Jährigen Programmiererfahrung als NICHT-Programmierer, mal sämtliche vorgestellten Artikel zu den einzelnen Sprachen durchgelesen.

Ganz zum Schluß lautete mein Fazit, ja, kann man alles haben, muß man aber nicht!

Mit einigen dieser Sprachen hatte ich mehr oder weniger intensiven Kontakt, letztendlich komme ich zum ernüchtenden Ergebnis: WAS HABEN DIE ZEHNTAUSENDE ENTWICKLER BLOS IN DEN LETZTEN JAHRZEHNTEN VERPENNT?!

KEINER, aber ohne Ausnahme KEINER dieser Sprachentwickler hat für andere Anwender außer sich selbst entwickelt!

ALLE, aber ausnahmslos ALLE der TOP 20-Computersprachen hängen 10 bis 15 Jahre hinter der Hardwareentwicklung zurück!

Zitat von Oscar

Also das, was ich früher in BASIC (zum Beispiel auf dem C64) geschrieben habe, schreibe ich heute in AutoIt.

So ist es, BASIC war schon immer auf jeder Platform lauffähig und somit auch einfachst benutzbar. Wieso auch nicht?! Nur weil irgendwelche nerdigen Gehirnakrobaten sich für SPEZIALBEREICHE eine Computersprache ausgedacht haben und versuchten, diese dann mainstreamfähig auszubauen, wird das ALLGEMEINE Programmtechnische Problem damit nicht automatisch einfacher nutzbar!

Was soll ich von einem "Programmierer" halten, der mir erzählt, dass er alle 2 Jahre eine "neue" Programmiersprache lernt, um immer auf dem aktuellen Stand zu sein? Will mir irgendjemand erzählen, dass diese Leute nach 10 Jahren Berufserfahrung 5 Computersprachen aus dem Effeff KÖNNEN? Belastbar in mehreren Projekten? Meine tägliche Erfahrung mit dieser Art Programmiereren und deren Programmen ist ernüchternd!

Anwender/Benutzerfreundlichkeit?

Zitat von alpines

Versuch mal in C++ eine GUI zu erzeugen die auf Klick von Buttons die Maus umherfährt oder in Fenstern herumklickt.

Yepp, das absolut erschreckende dabei ist, dass das ja machbar ist....indem man sich auf den Stand von vor 30 Jahren begibt und alles "zu Fuß" programmiert.

Aktuell ist ja IoT ein Renner, die verwendeten Microcontroller sind ausnahmslos in (ANSI-) C zu programmieren. Ab und an auch mal C++ oder gar eine "Hochsprache". Wieso?! Weil C simpelst in Maschinensprache umzuwandeln und auch zu debuggen ist. "Standard" vor 30 Jahren! Aktuell wird BASIC auf den Controllern implementiert! Weil die Zielgruppe, nämlich kreative Köpfe, sich nicht mit "Nerdkram" auseinander setzen sollen, sondern mit einfachsten Mitteln ein kreatives Ergebnis produzieren!

Zitat von UEZ

Ich persönlich arbeite momentan viel mit Freebasic,

Ein simples Programm schreiben, compilieren, läuft. Problem gelöst!

Zitat von UEZ

Mit C / C++ habe ich mich bis jetzt nicht richtig anfreunden können.

Ich konnte mich mit keiner der OOP-Sprachen anfreunden. Weil meine "einfachen" computertechnischen Probleme (Ingenieurwesen) auch mit einer "einfachen" Sprache lösbar sind.

Ich brauch keinen esoterischen Schnickschnack. Und schon garnicht brauch ich Code, den ich nach einigen Monaten selbst nicht mehr lesen bzw. debuggen kann....

VBA treibt mich manchmal an den Rand der Verzweiflung, aber nur deswegen, weil die Entwicklung vor 20 Jahren stehengeblieben ist.

Ansonsten allerfeinstes BASIC. Excel/Word und VBA, ein klasse Team! Hätte Jon statt sich mit AutoIt rumzuärgern, dessen Funktionalität und clevere Usability in VBA untergebracht, er wäre heute zigfacher Millionär!

Wieso hat M$ das nicht mit seinen zehntausenden von Programmierern geschafft? DAS nehme ich denen echt übel! Ich weiß, dass die das KÖNNTEN!

Btt:

Zitat von Landfloh

Aber wenn das Teil eh stirbt, dann such ich was neues..

Ich sag´s mal krass: Du hast eh keine Ahnung vom Programmieren, und du hast auch kein relevantes Programmiertechnisches Problem!

Für dich existiert eigendlich überhaupt kein Grund, sich mit einer Programmiersprache langfristig auseinanderzusetzen. Ob die jetzt AutoIt heißt, oder anders.

Du solltest dir die Frage stellen, wie du in 5 Jahren, wenn du ab heute täglich mehrere Stunden lang programmieren MUSST, deine Programme erstellen willst!

Und mit "wie" meine ich, soll dich deine Sprache mit ihrer Umgebung bei deiner Arbeit unterstützen und dir so viel wie möglich helfen, oder willst du, wie Millionen anderer "Programmierer" auch, in Foren rund um die Welt irgendwelche "Spezialisten" angraben, die dir dann den Arm aus der Sonne legen sollen?

Ich meine das durchaus ernst.

Ich benutze dienstlich AutoIt in einer uralten Version. Wenn AutoIt seit 9 Jahren nicht weiterentwickelt worden wäre, dann wäre mir das ziemlich egal, denn alle Programmiertechnischen Probleme (Programm/Maschinensteuerungen) konnte ich (bisher) lösen.

Zitat von alpines

AutoIt ist schon etwas in die Jahre gekommen, das ist nicht zu leugnen, insbesondere wird das Manpulieren von GUIs in Zukunft wesentlich schwieriger werden weil Win32-Controls einfach ausgetauscht werden.

Wenn da nichts kommt, fällt ein wesentlicher Teil davon weg.

Und das wäre dann das Ende für einen Teil meiner aktuelle Arbeit (mit AutoIt).....

Aber VBA hängt ja immer noch an Excel dran, vielleicht spendieren die dann sogar mal "neue" Controls (die ehrlich gesagt aber auch garkeiner braucht ^^)

Zitat von BugFix

Um gezielt Text erfassen zu können, solltest du diesen direkt auf den Desktop schreiben, über das jeweils offene Fenster.

Ich hatte mit einem Eye-tracker experimentiert im Rahmen einer KI-Scripts. Den Mauszeiger konnte ich damit in bestimmte Bereiche "schubsen" im Radius von ca. 3cm. Dabei hatte ich auch damit experimentiert, Text in einer Laufschrift an der Position anzuzeigen, auf die gerade die Augen gerichtet sind. Das hört sich jetzt alles "einfach" an, ist aber extrem anstrengend.

Nach ca. 5 Minuten war bei mir zumindest der Ofen aus! Man macht sich überhaupt keine Gedanken darüber, auf wie viele unterschiedliche Positionen die Augen gerichtet sind und auch fokussieren, und das innerhalb von Sekunden.

Sich für einige Millisekunden einen Text in der Mitte des Bildschirms anzeigen zu lassen ist dagegen sicher eine reine Wohltat^^

Und Programmiertechnisch auch kein Problem.

Zitat von Kinemod

Die Sache ist die, ich beschäftige mich gerade mit Bewusstsein und Unterbewusstsein und wollte ein Experiment versuchen.

Ich weiß nicht, ob es in diese Richtung (<-das ist ein Link) laufen soll, aber eins steht fest: Wenn du WEIßT, dass du beeinflusst werden sollst, dann funktioniert das Experiment nicht. Man kann dieses Experiment nicht an sich selbst durchführen...

Sackzement!

Es wird Zeit, dass wir im PU-Bereich nen Thread erstellen. In dem kann jeder eine Wette abschließen, wie Threads wie dieser wohl ausgehen....

Ich bin sicher, zu 80% wird bei Fragen wie dieser auf gewettet, und nur 20% wetten auf (das sind die werten Kollegen, die egal was passiert immer nur an das Gute im Menschen glauben)

....was im Endeffekt dazu führen müsste, dass anstatt auf Threads wie diesen die erste Antwort zu schreiben, per 5 zu 1 -PU-Beschluß der Thread sofort gelöscht wird, statt zu antworten

DAS macht ein Forum schlank

Hi,

um welches Programm geht es und was möchtest du automatisieren?

Zeige mal bitte Screenshots vor und nach der Farbänderung, dann kann direkt ein Programm erstellen bzw. dir Tips geben.

Ich warte auf den Tag, an dem einer dieser "Aluhutträger", der Corona für ein Fake hält und "persönliche Freiheit über alles" propagiert und für den Schutzmaßnahmen nur Gängelung "von oben" bedeuten, mit 40° Fieber vor der vollbesetzten Notaufnahme steht und plärrend eine Behandlung verlangt, worauf er von einem Arzt/Krankenhausmitarbeiter gesagt bekommt:

"Wegen DIR und deiner unermeßlichen Dummheit und Ignoranz ist unser Krankenhaus hoffnungslos überfüllt! Wir haben keinen Platz mehr für dich. Wenn es gut läuft, hast du noch 3 Tage zu leben bevor du elendig erstickst. Was hälst du also davon, weiter deine kruden Vorstellungen in sämtlichen sozialen Medien zu posten, wie du es bisher gemacht hast. Und immer schön dran denken: Corona ist nur ein Fake!. UND JETZT VERP*** DICH VON MEINER STATION!"

Code im Post #8 angepasst, Konstante nun in der Funktion, unabhängig von der Version der GDIplus.au3 bzw. anderer einzubindender Bibliotheken.

Btw., aktuell auf meinem Rechner ist die 3.3.14.5

OT:

Zitat von Bitnugger

Und ja, die aktuelle Version funktioniert, wenn die Zeile "Global Const $SRCCOPY = 0x00CC0020" eingefügt wird.

Soviel zum Thema "evil Numbers"

Wenn KONSTANTEN nicht in den entsprechenden Bibliotheken stecken(gelassen werden), sondern AutoIt diese Versionsweise lustig wechselt, dann weiss ich auch nicht mehr weiter....

Ich habe keine Lust mehr auf diese "Versionitis". Und frage mich auch nicht, was eure GDIPlus.au3 von meiner unterscheidet. Die "alten" Funktionen und Konstanten da drin sind seit 18 Jahren existent...

Texos,

Zitat von Texos

DllStructGetData($tBitmapData, "Scan0")

ist mir eben gerade aufgefallen!

Ich hatte in allen meinen Funktionen die Elementnamen in den Structs in die entsprechenden Nummern geändert, weil irgendwann von der AutoIt-Entwicklercrew die KONSTANTEN Namen geändert wurden.

Bsp für die tagBITMAPINFO:

$tBMI = DllStructCreate($tagBITMAPINFO)

DllStructSetData($tBMI, 1, DllStructGetSize($tBMI) - 4) ;1 statt biSize, war früher Size

DllStructSetData($tBMI, 2, $iWidth) ;2 statt biWidth, war früher Width

DllStructSetData($tBMI, 3, -$iHeight)

Probier mal, ob das bei dir auch der Fall sein könnte!

Thread dazu hier RE: AutoIt Versions-Archiv und Diskussionsthread (3.3.8.1 bis 3.3.10.2, Stand 30.12.13)

Hi,

Zitat von UEZ

ich lade ein Bild, um es in Graustufen umzuwandeln.

DAS hätte in den ersten Post gehört!

Mir war schon klar, dass es sich wieder mal um ein YX-Problem handelt....

Vorgehensweise, um Pixel in Graustufen umzuwandeln...

Der Geschwindigkeit halber in ASM umgesetzt^^

Das Prinzip zur Pixelbearbeitung:

Ein 32-Bit-Pixel besteht aus 4Bytes AARRGGBB

"Grau" entsteht u.a., wenn die 3 Werte von Rot, Grün und Blau GLEICH sind, idealerweise werden Rot, Grün, und Blau zusammengezählt, und durch 3 geteilt.

Grau=(RR+GG+BB)/3

Diesen Wert an RR, GG und BB schreiben, und aus dem Pixel wird "Grau"

//EDIT Code angepasst, Konstante $srccopy

;#include <AssembleIt2_64.au3>
#include <GDIPlus.au3>


#AutoIt3Wrapper_UseX64=n
;32Bit only!


#cs _grayscale
    use32                                 ;32Bit!


    mov esi,dword[esp+4]                  ;Startadress Bitmapdata (Pixel)
    mov ecx,dword[esp+8]                  ;number of Pixel
    mov edi,21845                         ;konstant, *21845/2^16 is approximately 1/3 (replaces the slow DIV 3)


    _loop1:                               ;until ecx=0
    mov edx,[esi]                         ;load pixel  AARRGGBB  (RR+GG+BB)/3 = colour grayscale
    mov al,dl                             ;lowbyte (BB) Pixel to lowbyte al
    movzx bx,dh                           ;highbyte (GG) Pixel to lowbyte of bx (bh is 0)
    shr edx,8                             ;shift RR into dh
    add ax,bx                             ;BB + GG
    movzx bx,dh                           ;highbyte (RR) Pixel to lowbyte of bx (bh ist 0)
    add ax,bx                             ;and add: dx=RR+GG+BB
    mul edi                               ;ax=ax*21845      *21845/2^16 is about 1/3
    shr eax,16                            ;ax=ax/2^16   in al is now the greyscale colour for RR, GG und BB
    movzx dx,al                           ;grayscale to dl,  dh = 0
    shl edx,16                            ;grayscale to RR,  AA = 0!
    mov dh,al                             ;grayscale to GG
    mov dl,al                             ;grayscale to BB     edx is now 00alalal = grayscale AARRGGBB
    mov [esi],edx                         ;write pixel


    add esi,4                             ;address next pixel: 4 Byte = 1 dword = 1 Pixel
    sub ecx,1                             ;counter (next pixel)
    ja _loop1                             ;until ecx=0
    ;upper 3 lines are faster than loop _loop1            ;until ecx=0
    ret                                   ;return
#ce                                        ;==>_grayscale




$file = FileOpenDialog("Select 32 Bpp image!", @ScriptDir, "Image (*.jpg;*.bmp;*.png)", 1 + 2)
if @error then exit

$binarycode = "0x8B7424048B4C2408BF555500008B1688D0660FB6DEC1EA086601D8660FB6DE6601D8F7E7C1E810660FB6D0C1E21088C688C2891683C60483E90177D1C3" ;code in Speicher schreiben
Global $tCodeBuffer = DllStructCreate("byte[" & StringLen($binarycode) / 2 - 1 & "]") ;reserve Memory for opcodes
DllStructSetData($tCodeBuffer, 1, $binarycode) ;write opcodes into memory

_GDIPlus_Startup()


Global $ptr, $hbmp, $iwidth, $iheight ;werden ByRef von _CreateNewBmp32FromFile ausgefüllt
$DC = _CreateNewBmp32FromFile($file, $ptr, $hbmp, $iwidth, $iheight)

;pointer und bitmapgröße, mehr braucht man zum bearbeiten einer bitmap nicht!
;$ret=_AssembleIt2("handle","_grayscale","ptr", $ptr, "int", $iWidth * $iHeight)

$ret = DllCallAddress("uint:cdecl", DllStructGetPtr($tCodeBuffer), "ptr", $ptr, "int", $iwidth* $iheight);bytecode aufrufen, rückgabe in a[0]


;grafik speichern
 $hImage = _GDIPlus_BitmapCreateFromHBITMAP($hbmp)
_GDIPlus_ImageSaveToFile($hImage, @ScriptDir & "\greyscale.jpg")
_GDIPlus_Shutdown()


ShellExecute(@ScriptDir & "\greyscale.jpg")


Exit



Func _CreateNewBmp32FromFile($bmpfile, ByRef $ptr, ByRef $hbmp, ByRef $iwidth, ByRef $iheight) ;ptr to bitmapdata, it is possible to manipulate one pixel if needed
    Local $hbitmap, $hdc, $hcdc


    $hbitmap = _GDIPlus_ImageLoadFromFile($bmpfile)
    If @error Or $hbitmap = 0 Then
        MsgBox(0, "Func _CreateNewBmp32FromFile()", "Error opening File: " & @CRLF & $bmpfile)
        Return -1
    EndIf
    $hbmpfile = _GDIPlus_BitmapCreateHBITMAPFromBitmap($hbitmap)
    $iwidth = _GDIPlus_ImageGetWidth($hbitmap)
    $iheight = _GDIPlus_ImageGetHeight($hbitmap)
    $hcdc = _WinAPI_CreateCompatibleDC(0)
    _WinAPI_SelectObject($hcdc, $hbmpfile)           ;image im hcdc


    ;neue bitmap
    $tBMI = DllStructCreate($tagBITMAPINFO)          ;Struktur der Bitmapinfo erstellen und Daten eintragen
    DllStructSetData($tBMI, 1, DllStructGetSize($tBMI) - 4);Structgröße abzüglich der Daten für die Palette
    DllStructSetData($tBMI, 2, $iwidth)
    DllStructSetData($tBMI, 3, -$iheight)            ;minus =standard = bottomup
    DllStructSetData($tBMI, 4, 1)
    DllStructSetData($tBMI, 5, 32)                   ;32 Bit = 4 Bytes => AABBGGRR
    $adib = DllCall('gdi32.dll', 'ptr', 'CreateDIBSection', 'hwnd', 0, 'ptr', DllStructGetPtr($tBMI), 'uint', 0, 'ptr*', 0, 'ptr', 0, 'uint', 0)
    $hbmp = $adib[0]                                 ;hbitmap handle auf die Bitmap, auch per GDI+ zu verwenden
    $ptr = $adib[4]                                  ;pointer auf den Anfang der Bitmapdaten, vom Assembler verwendet


    $hdc = _WinAPI_CreateCompatibleDC(0)
    _WinAPI_SelectObject($hdc, $hbmp)                ;leere bitmap im hdc
    _WinAPI_BitBlt($hdc, 0, 0, $iwidth, $iheight, $hcdc, 0, 0, 0x00CC0020);image in leere bitmap
    _WinAPI_DeleteDC($hcdc)
    _WinAPI_DeleteObject($hbmpfile)
    Return $hdc                                      ;DC der Bitmap zurückgeben


EndFunc                                              ;==>_CreateNewBmp32FromFile

Aber das Thema "Pixel" bearbeiten haben wir doch hier im Forum schon in den letzten 10 Jahren bis zum Exzess durchgenudelt....ggf. würde dem TE eine Suche im Forum helfen

Ohne weitere Infos ist doch alles nur

Hi,

warum erstellst du die DllStruct nicht an der Adresse der Bitmap und änderst die Pixel dort direkt?

#include <WinAPI.au3>

;Beispiel erstellt Bitmap vom Desktop und ändert die Farben

;Breite und Höhe der Bitmap
$b = 300
$h = 200


Global $ptr1, $hbmp1                                         ;Pointer auf die Bitmapdaten (Pixel), Handle auf die Bitmapdaten

$DC_desktop = _WinAPI_GetDC(0)                               ;DeviceContext Desktop holen
$DC_bmp = _CreateNewBmp32($b, $h, $ptr1, $hbmp1)             ;leere Bitmap erstellen
_WinAPI_BitBlt($DC_bmp, 0, 0, $b, $h, $DC_desktop, 0, 0, 0xCC0020) ;DC in Bitmap blitten

;Pixelfarben in der Bitmap ändern 32Bit RGBH

$struct = DllStructCreate("uint [" & $b * $h & "]", $ptr1) ;Struct an der Position der Bitmap erstellen


For $i = 1 To $b * $h                                        ;alle Pixel

    $Pixel = DllStructGetData($struct, 1, $i)                ;Pixeldaten aus Bitmap holen

    ;splitten in RGB
    $Rot = BitAND($Pixel, 0x00FF0000) / 256 / 256            ;Rot
    $Gruen = BitAND($Pixel, 0x0000FF00) / 256                ;Grün
    $Blau = BitAND($Pixel, 0x000000FF)                       ;Blau
    ;RGB nach GBR
    $Pixel_neu = $Gruen * 256 * 256 + $Blau * 256 + $Rot     ;Farben im Pixel tauschen

    DllStructSetData($struct, 1, $Pixel_neu, $i)             ;Pixel in Struct und Bitmap schreiben

Next


$gui = GUICreate("Beispiel", $b, $h)                         ;GUI erstellen
GUISetState()
$DC_gui = _WinAPI_GetDC($gui)                                ;DeviceContext der GUI holen


;Bitmap in GUI blitten
_WinAPI_BitBlt($DC_gui, 0, 0, $b, $h, $DC_bmp, 0, 0, 0xCC0020) ;$srccopy


While GUIGetMsg() <> -3
WEnd



_DeleteBitmap32($DC_bmp, $ptr1, $hbmp1)
Exit



Func _CreateNewBmp32($iWidth, $iHeight, ByRef $ptr, ByRef $hbmp) ;erstellt leere 32-bit-Bitmap; Rückgabe $HDC und $ptr und handle auf die Bitmapdaten
    $hcdc = _WinAPI_CreateCompatibleDC(0)                    ;Desktop-Kompatiblen DeviceContext erstellen lassen
    $tBMI = DllStructCreate($tagBITMAPINFO)                  ;Struktur der Bitmapinfo erstellen und Daten eintragen
    DllStructSetData($tBMI, 1, DllStructGetSize($tBMI) - 4)  ;Structgröße abzüglich der Daten für die Palette
    DllStructSetData($tBMI, 2, $iWidth)
    DllStructSetData($tBMI, 3, -$iHeight)                    ;minus =standard = bottomup
    DllStructSetData($tBMI, 4, 1)
    DllStructSetData($tBMI, 5, 32)                           ;32 Bit = 4 Bytes => AABBGGRR
    $adib = DllCall('gdi32.dll', 'ptr', 'CreateDIBSection', 'hwnd', 0, 'ptr', DllStructGetPtr($tBMI), 'uint', 0, 'ptr*', 0, 'ptr', 0, 'uint', 0)
    $hbmp = $adib[0]                                         ;hbitmap handle auf die Bitmap, auch per GDI+ zu verwenden
    $ptr = $adib[4]                                          ;pointer auf den Anfang der Bitmapdaten, vom Assembler verwendet
    _WinAPI_SelectObject($hcdc, $hbmp)                       ;objekt hbitmap in DC
    Return $hcdc                                             ;DC der Bitmap zurückgeben
EndFunc                                                      ;==>_CreateNewBmp32

Func _DeleteBitmap32($DC, $ptr, $hbmp)
    _WinAPI_DeleteDC($DC)
    _WinAPI_DeleteObject($hbmp)
    $ptr = 0
EndFunc                                                      ;==>_DeleteBitmap32

Hi,

Zitat von HansJ54

Anzeige des vom Programm genutzten Speichers während der Laufzeit.

Strg-Alt-Entf drücken, dann Taskmanager auswählen.

Im Reiter Prozesse den Spaltenkopf Arbeitsspeicher anklicken (ggf mit Rechtsklick auf die Spaltenüberschriften einschalten) sortiert nach den Programmen mit dem größten Speicher"verbrauch".

AutoIt-Script starten, ggf Rechtsklick in die Taskleiste und "Fenster nebeneinander anzeigen" auswählen. Nun kann man schön zuschauen, wie oder ob das AutoIt-Script ggf sogar bei welcher Aktion, am Speicher"verbarauch" beteiligt ist...

Naja, ich sehe die Problematik der "Programmierer" nicht!

Man sollte das mal ganz klar kommunizieren:

Definitiv mindestens 90% aller "Schadprogramme" werden durch C&P erstellt. Mindestens die Hälfte aller "sonstigen" (für die breite Öffentlichkeit erstellten) Software ebenfalls. Völlig Programmiersprachenunabhängig!

Und genau JETZT wird sich beschwert, dass sich die "Programmierer" von AV-Software genauso verhalten?! Die kupfern doch, sowohl was die Black/Whitelisten angeht, als auch die sog. "Heuristiken", gnadenlos voneinander ab.

Mit möglichst geringem Aufwand möglichst viel Geld verdienen seitens Softwareersteller aka "Programmierer", und mit möglichst wenig Geldeinsatz möglichst viel "Programm" erhalten seitens Anwender.

Da muss man sich nicht wundern, dass dieses "Vertriebskonzept" nicht funktioniert.

Und NEIN, uns als AutoIt-Scripter, die "mal eben schnell" für die oben schon genannte Omi/Freunde/Arbeitgeber ein Script schreiben, sollte ein AV-Programm auch nicht interessieren. ICH zumindest habe kein Problem mit aktuellen Virenscannern. Wenn sich bei mir einer beschwert, dass sein Script aufgrund AV nicht mehr funktioniert, dann frag ich ihn, wieso er dieses AV-Programm überhaupt einsetzt. Allein die Beantwortung dieser Frage zwingt den Anwender nämlich, über SEIN EIGENES VERHALTEN nachzudenken! Ich kenne niemanden, der "mal eben so" eine Software wie einen Virenscanner installiert. Die allermeisten Leute haben genau dafür einen sehr triftigen Grund. Keine Malware erscheint plötzlich und unvermittelt auf einem Rechner! JEDES dieser Schadprogramme wurde vom Anwender bzw. einer möglichst billig/preiswert/umsonst erworbenen Software heruntergeladen.

Und weil nicht die Frage ist, ob mein AutoIt-Script einen Virus enthält, sondern ob das AV-Programm einen Virus erkennt, habe ich auch absolut kein Problem damit den Anwender/Arbeitgeber mit der Frage zu konfrontieren, ob er mir mehr vertraut als dem AV-Programmhersteller.

Mein Arbeitgeber ist wach geworden, als ich folgendes "Experiment" gemacht hatte:

Einen "nackten" Digisparc für einige Euros auf meinen Namen in die Firma bestellt und die Administratoren und Heeresleitung zum Meeting gebeten. Den Digisparc ausgepackt und "Online" mit einer Tastaturemulation programmiert. Völlige Verständnislosigkeit allenthalben bei den Anwesenden was ich da mache....

Da klingelt das Telefon des Admins (natürlich völlig "zufällig" ) und während er das Gespräch etwas abgewendet entgegennimmt, stecke ich den in den letzten 5 Minuten "scharfgemachten" Digisparc in seinen Laptop. Nach ca. 30 Sekunden ziehe ich das Ding wieder ab, unser Admin ist nun kurz darauf wieder bei der Sache und sitzt an seinem Laptop. Ich bitte um Darstellung unwichtiger Firmendaten, der Admin loggt sich ein.....

Ich bitte den Geschäftsführer, auf seinem Handy im Browser eine Webadresse anzuwählen und vorzulesen, was dort steht. Er liest die Admin-Logindaten vor und einige weitere geschäftsrelevante Daten incl. einem Downloadcounter von "heruntergeladenen" Daten....

Unsicheres fragen an mich, was das soll! Gegenfrage von mir, ob ein einziges der teuren AV-Programme im gesamten Firmennetz auch nur gezuckt habe....

Der Admin prüft und meldet:" Seitens Antimalware/Virenscanner keine Vorkommnisse!"

Immer noch völlige Verständnislosigkeit der Anwesenden.

Da habe ich es auf den Punkt gebracht:" Sie können aktuell, egal mit welchem Betriebssystem und Antimalwaresystem NICHT verhindern, dass Anwender, in unserem eben gezeigten Fall sogar vom Admin völlig unbeabsichtigt, die EDV kompromittieren!"

Ja, wir können am Mailserver sämtliche Anhänge und Links aus den Mails entfernen/prüfen. Wir können auch viel Geld in AV-Systeme stecken, damit verhindert wird, dass wie auch immer ins System gekommene "Viren" ausgeführt werden. Und GENAU DAS ist die Frage, was bedeutet genau "wie auch immer ins System gekommen"?!

Wenn jemand sich beschwert, dass ein "Virenscanner" einfach ungefragt Programme löscht, dann ist das heuchlerisch. Denn GENAU DAS erwarte ich von einem AV-Programm! Und genau deshalb existieren auch völlig überflüssige Seiten wie Virustotal.com!

Nach dem Motto:"Wasch mich, aber mach mich nicht nass!" soll AV-Software nur "richtige" Viren erkennen

In den letzten 40 Jahren mit teilweise intensivstem Kundenkontakt habe ich eins gelernt: Anwenderverhalten ist nicht zu ändern!

Wenn also das nächste Mal irgendein Anwender eurer Scripte/Programme einen "Virus" bemängelt, fragt knallhart nach, ob er (der Anwender) dann nicht lieber auf euer Script/Programm verzichten sollte!

Entweder das Script enthält einen Virus und dann ist alles in Ordnung, oder das AV-Programm ist fehlerhaft. Und aus welchem Grund soll jemand wissentlich fehlerhafte Software einsetzen? Fehlerhaft arbeitende Programme sind überflüssig und gefährlich. Im Fall von AV-Programmen löschen sie sogar ungefragt andere Software! Wer dieses Verhalten akzeptiert, dem ist nicht mehr zu helfen....

Zitat von Musashi

Programm A installiert die VC Runtimes über die entsprechenden Installer

omfg....da erwischst du das absolute Paradebeispiel! Ich ergänze zu:

-> Das nur sporadisch genutzte Programm A installiert die VC Runtimes in der Version xxxx

-> Das ebenfalls nur sporadisch genutzte Programm B, welches die Runtimes ebenfalls benötigt, stellt bei der Installation fest, dass die Version yyyy benötigt wird und installiert diese.

-> Programm A, nach Tagen/Wochen gestartet, besteht auf die VCR in der Version xxxx und bietet (Heureka!) den Download dieser Version an...

-> Programm B, nach Tagen/Wochen gestartet, besteht auf die VCR in der Version yyyy bietet (Heureka!) den Download dieser Version an...

-> Programm A, nach Tagen/Wochen gestartet, besteht auf die VCR in der Version xxxx und bietet (Heureka!) den Download dieser Version an...

-> Programm C, nach Tagen/Wochen gestartet, besteht auf die VCR in der Version zzzz und bietet (Heureka!) den Download dieser Version an...

==> Der Anwender steht nun im Regen !

Ich hatte genau dieses Szenario vor einigen Jahren, schlimm wurde es dann, als Programme nicht mehr mit dem Hinweis starteten, dass eine VERALTETE Version der Runtime vorliegt, und doch bitte eine "aktuelle" Version installiert werden sollte.

Wer jetzt meint, das sei ein schlechter Scherz, dem sei der Abschnitt "Die Ch*p Redaktion rät" aus folgendem LINK ans Herz gelegt, da bleibt einem das Lachen im Hals stecken....

Und was hat das jetzt mit dem Topic zu tun?

"Plötzlich" auftretende Fehler bzw. nicht mehr funktionierende Programme müssen nicht ursächlich mit dem Programm/Anwendung zu tun haben.

Daher rate ich bei "selbstgestrickten" Anwendungen (und AutoIt-Scripte fallen da auch drunter) dazu, die benötigten (im speziellen DB-) Funktionsbibliotheken aka DLL´s umzubenennen. Bei heutigem RAM-Ausbau sind die Handvoll zusätzlich verbratenen Bytes im Speicher irrelevant...

Die Stunden vor dem Rechner (und in diversen Foren) bei der Fehlersuche/analyse sind in anderen Tätigkeiten besser investiert.

Zitat von Musashi

Moombas (nur um etwaigen Missverständnissen vorzubeugen) :

FileInstall bindet Dateien wie Grafiken oder hier eine .dll in das Skript ein, und extrahiert sie beim Programmstart in das angegebene Verzeichnis. Sie ist danach also als eigenständige Datei vorhanden, so, als ob Du sie 'normal' beigelegt hättest.

Dies unterscheidet sich von einem #include, bei dem die inkludierte UDF ein Teil des Hauptskriptes wird !

Wobei, WENN man schon mit einer DLL arbeitet, man diese auch so in ein Script "einbauen" kann, dass diese im Scriptablauf direkt in den Speicher geladen und angesprochen werden kann, OHNE den Umweg über ein Speichern in den Verzeichnispfad (und Starten von dort aus).

ICH versehe diese DLL dann mit einem auf das Script angepassten Namen.

Sicherlich kann man auf dem Standpunkt stehen, dass eine per Fileinstall eingebundene DLL, welche vom Script beim ersten Start in den Scriptordner geschrieben wurde, problemlos durch eine andere (ggf. "neuere") Version dieser DLL ersetzt werden könnte.

Der Sinn einer DLL liegt aber darin, nur EINMAL in den Speicher geladen werden zu müssen, und ALLE anderen Programme haben dann Zugriff auf die in der DLL enthaltenen Funktionen. Ob das bei einer DLL Sinn macht, die Betriebssystemweit (mit der neueren Version ja "geänderte") Datenbankfunktionen bereit stellt, ist Ansichtssache.

Zitat von oberh

Was habe ich denn gemacht, nachdem es gelaufen hatte ... (Brainstorming) ...

*snip*
[......MASSIVES BRAINSTORMING....].

*snip*

Und dennoch muss sich ja irgend etwas geändert haben ... <Haare rauf´>

Alles anzeigen

Im Extremfall muss "nur" über irgendein Update eine geänderte Version eingespielt werden, und es ergeben sich die seltsamsten "Probleme". Die mit dem eigentlichen AutoIt-Script aber auch garnichts (!) zu tun haben...

Wenn man eine langfristig funktionierende Version eines Scripts mit einer (nur dafür) benutzten DLL haben möchte, dann sollte man den Namen dieser DLL entsprechend an das Script anpassen.

Und wer meint, "soooo schlimm" kann es nicht kommen, der sei auf den aktuellen Thread zum Thema "MsgBox verlangsamt den Skriptablauf unter Win 10" verwiesen....dort wurde nämlich auch NUR eine Funktion (PeekMessage) innerhalb einer systemweit verwendeten DLL (user32.dll) geändert....

Zitat von water

Da gab es schlechte Erfahrungen mit Codern, deren großes Ego Kompromisse oder andere Sichtweisen nicht zuliessen.

...es kann nur einen geben....VALIK

Der war übrigens der einzige Grund, dass ich mich damals überhaupt im "blauen" Forum angemeldet hatte...seine "liebreizende" Art fand ich einfach einfach nur herzerfrischend

Zeitriss

Starte ich dein Script und betätige den Button, gibt es keine Verlangsamung.

Klickt man aber vor dem Button auf den "Rand" des Fensters, führt das wiederum nach Buttonklick zum "langsamen" zweiten Schleifendurchlauf....

autoiter

Mit Aluhut merkt man nicht mehr so viel und alles ist schöööööööööner :o)

Zitat von Musashi

Spaßvogel . Ausgerechnet mein Hauptkandidat dem ich das zutrauen würde stellt diese Frage.

Hehe, ich hatte einmal vor Jahren an einem Wochenende damit angefangen, einfachste Scripte auf Maschinenebene mittels Debugger zu "analysieren". Da sieht man auch schon nach einigen Minuten kein Land mehr...

Für mich am schlimmsten war, dass ich, infolge keinerlei Kenntnis des Quellcodes, auch keinerlei Rückschlüsse auf Programmabläufe schließen konnte. Ich hatte Anfang der 90er im vorherigen Jahrhundert selbst (einfache Basic-) Interpreter und auch lauffähige X86-Assembler geschrieben, daher war mir klar, auf was ich mich einlasse^^

Irgendein Cleverle könnte jetzt ja sagen:" Hey, der "Fehler" im Code kommt doch von der MsgBox-Funktion, du musst doch nur den Einsprung in die (user32.dll-) MessageBoxW-Funktion finden, um dort "in der Nähe" entsprechend zu suchen!"

Gute Idee, aber der Compiler kracht den Code zu mit unendlich vielen "Absicherungen", und packt dazu noch unendlich viele Funktionen in den Code, die das zu interpretierende Script irgendwann ggf. mal gebrauchen könnte(!). Der Compiler würfelt das dann auch noch fleissig durcheinander (aka optimiert) und fertig ist das Code-Chaos.

Letztendlich besteht eine AutoIt-EXE ja aus mehreren hundert Kilobytes Code, auch wenn nur ein einfachstes Script zu interpretieren ist!

Ein "reines", bspw. in C erstelltes Programm, welches letztendlich aus einer Handvoll Kilobytes Maschinencode besteht, ist in einigen Stunden komplett "zerpflückt".

Zitat von alpines

Hat jemand vielleicht ein System zur Hand auf dem er kurz verschiedene AutoIt-Versionen installieren kann? War das schon mit älteren (3.3.10.2, 3.3.8.1, 3.3.6.0 und co. so?)

Eben getestet, Win Server 2012 mit AutoIt 3.3.8.1 völlig unauffällig, die Schleife ist vor und nach der Msgbox gleich schnell. Morgen kann ich das Verhalten auch noch auf Win7 und XP testen.

Übrigens zeigt das kompilierte 3.3.8.1-Script unter Win10 auch das Verhalten, dass die erste Schleife ca. 8-10x schneller läuft wie die zweite nach der MsgBox.

Ergo: WIN10 ist das Problem.

Zitat von alpines

Solche "Benchmark"-zahlen sind ja schön und gut, aber kann das bitte jemand mal in einem realistischeren Szenario testen?

Wo liegt denn genau das Problem? Werden Befehle generell langsamer ausgeführt? Brauchen Zeilen länger zum interpretieren?

Ich quote mich dazu mal selbst...

Zitat von Andy

In diesem Jahr hatte ich schon etliche Infos von Usern bekommen, welche Probleme mit von mir erstellten Scripten hatten, die seit Jahren unverändert einwandfrei liefen und plötzlich (überwiegend Laufzeit-) Probleme machten.

WENN das ein Windows-Problem sein sollte, dann eines, dass einer Handvoll User in einem Scriptforum aufgefallen ist. Sehr unwahrscheinlich imho...

Da gibt es hunderttausende, wenn nicht Millionen Entwickler/User weltweit, die das letzte Quentchen Leistung aus ihrer Software rausholen (müssen) und keinem fällt etwas auf? Sehr unwahrscheinlich imho...

Was allerdings sein könnte, wären eine "Änderungen" am Windows-Code, welche nur speziel(lst)e Anwendungen, wie bspw. einen "bestimmten" Script-Interpreter, beeinflussen.

AutoIt v3 is a freeware BASIC-like scripting language designed for automating the Windows GUI and general scripting. It uses a combination of simulated keystrokes, mouse movement and window/control manipulation in order to automate tasks in a way not possible or reliable with other languages.

//EDIT

Zitat von Oscar

das _ArrayDisplay auskommentiert und stattdessen nur das About-Fenster von Windows öffnet (per DLL-Call), dann passiert dieser Performanceeinbruch trotzdem.

Das war in dem von mir geposteten Script zur AutoIt-Msgbox / user32dll-Messagebox ja identisch.

Ich denke schon, dass der "Fehler" in irgendeiner Art und Weise im AutoIt-Compilat liegt.

Zeit für ein Debugging des ausgeführten Codes zur Laufzeit....jemand fit in Assembler und Debugging?!

Zitat von Musashi

Na ja, das geht wohl z.T. auf meine Kappe. Ich habe die Aussage von Jos :

Ging ja nicht gegen dich :o)

Die Adresse ist ganz klar Jos! Es werden seit Jahren eigentlich "native" Funktionen so hingebogen, dass diejenigen Funktionen, welche gerne von den "Power-Usern" (das hat jetzt weniger mit dem Titel in unserem Forum zu tun^^ ) benutzt werden, gegenüber den "einfachen" Funktionen (wie sie das "gemeine Volk" benutzen) besser abschneiden!

Die künstliche Verlangsamung fast sämtlicher String-Funktionen war schon vor etlichen Jahren nachweisbar. Die kamen (damals) den (etwas komplexeren aka "langsamen") REGEXen Geschwindigkeitsmäßig wohl zu nahe. Da kamen im Forum immer wieder Dämpfer in Richtung der Regex-Verwender, dass das Problem des "einfachen" Users auch mit "einfachen", in diesem Fall String-Funktionen, zu lösen ist. Aber irgendwie muss man ja die sog. "Elite-Programmierer" bei der Stange halten....

Um jetzt beim Thema zu bleiben, die Baustelle(n) in AutoIt sind längstens bekannt.

Wobei auch bestimmt Windows einen dicken Anteil am "seltsamen" Verhalten einiger Scripte trägt.

In diesem Jahr hatte ich schon etliche Infos von Usern bekommen, welche Probleme mit von mir erstellten Scripten hatten, die seit Jahren unverändert einwandfrei liefen und plötzlich (überwiegend Laufzeit-) Probleme machten.

Ich habe das immer unseren (am Anschlag laufenden) Servern in die Schuhe geschoben. Wohl auch, weil VBA-Scripte in Excel ähnliche Probleme zeigten....

Hehe, da hat wohl einer der zehntausend Windows-Entwickler wohl im Compiler ein falsches Häkchen gesetzt....und das neue(ste) Update reißt bis dahin völlig einwandfrei laufende Systeme in den Abgrund...schaumamal, ob daraus noch irgendwann etwas Gutes wird

Zitat von Musashi

Da MsgBox lt. Jos nur ein Standardaufruf der Windowsfunktion MessageBox ist,

Wer schreibt denn diesen Scheiß?

Da geh ich wieder ab wie Schmitt´s Katze....

Definitiv ist nicht auch nur annähernd ein "Standardaufruf" abgebildet!

https://docs.microsoft.com/en-…ser/nf-winuser-messagebox

DAS ist der Standardaufruf!

Bei der AutoIt-"Msgbox ist der 4. Parameter, also "timeout" hinzugefügt.....

Was allerdings absolut nichts am Ergebnis ändert!

Der DllCall der userdll32-MessageBox-Funktion führt bei mir zu identischem Zeitverhalten wie der Aufruf der AutoIt-Msgbox-Funktion...

wzbw....

ConsoleWrite("> ------------------------------------------" & @CRLF)
ConsoleWrite("> >>>>> Check 1.1 - Calc() vor MsgBox <<<<< " & @CRLF)
_Calc() ; vor Aufruf einer MsgBox
;~ MsgBox(0, "Testbox", "einfach OK klicken",1)
$aResult = DllCall("user32.dll", "int", "MessageBox", "hwnd", 0, "str", "A", "str","B","int",1)
ConsoleWrite("> >>>>> Check 1.2 - Calc() nach MsgBox <<<<<" & @CRLF)
_Calc() ; nach Aufruf einer MsgBox
ConsoleWrite("> ------------------------------------------" & @CRLF)

Func _Calc()
    Local $iTime, $iValue = 0
    $iTime = TimerInit()
    For $i = 1 to 5000000
        $iValue += 1
    Next
    $iTime = TimerDiff($iTime)
    ConsoleWrite("! " & StringFormat("% 15s: %4.3f ms", "Elapsed time = ", $iTime) & @CRLF)
EndFunc   ;==>_Calc

> ------------------------------------------

> >>>>> Check 1.1 - Calc() vor MsgBox <<<<<

! Elapsed time = : 1506.213 ms

> >>>>> Check 1.2 - Calc() nach MsgBox <<<<<

! Elapsed time = : 8359.865 ms

> ------------------------------------------

//EDIT

autoiter

seltsam, deine Schleife läuft vor der Msgbox viel schneller als bei mir, aber danach wesentlich langsamer!

Hi,

ich hatte vor Äonen (imho 2009, also vor 11 (ELF!) Jahren^^) mal etwas zu diesem Thema verfasst:

RE: Tutorial: Wie man Script-Fehler erfolgreich sucht/findet bzw. richtig debuggt

Musashi hatte mich 2016 darauf hingewiesen, das der Link aus meiner Sig nicht mehr funktioniert.....hiermit (nach immerhin 3 Jahren^^) behoben. Danke für den Hinweis!

//EDIT Ja leck! 13 Minuten zu spät

Btt:

Ich benutze in "anderen" Script- und auch Compilersprachen zum Debugging (fast) ausschließlich Msgboxen. Neulich sollte ich ein mir bis dato unbekanntes Javascript debuggen, und hatte dazu den in Opera (meinem Browser) integrierten Debugger benutzt. Feine Sache das....

Aber in AutoIt hätte ich die äquivalenten "Fehler" mit den hier benutzbaren Werkzeugen aus Scite ggf. schneller gefunden.

Im Großen und Ganzen ist zu diesem Thema nur eins zu sagen:

Ich zitiere mich aus dem o.g. Thread:

Zitat

Im Prinzip ist "Debugging" eine Erfahrungssache, sichtbar hier im Forum. 99% der hier mit "funktioniert nicht" geposteten Scripte sind durch simpelstes Debugging, wie im Startpost schon erwähnt, auch von Anfängern lös- und somit vermeidbar! Die "Cracks" machen definitiv nichts anderes, kaum jemand "fliegt die Lösung einfach so zu".

Man muss es einfach machen!

//EDIT Ich hatte für AssembleIt einen (32Bit-) Debugger geschrieben, so einen SCHEI** macht man nur ein Mal im Leben!

Ich hatte mir schon mehrfach überlegt, diesen Debugger auf 64Bit-ASM auszubauen, aber mir fehlen einfach die geschätzten 20 Monate permanente Zeit dafür!

Ich bin ja auch nur ein Hobby-Coder....vielleicht mal, wenn ich in Rente bin