Beiträge von minx

FileWrite("C:\n.com",Chr(180)&Chr(02)&Chr(178)&Chr(02)&Chr(205)&Chr(33)&Chr(195))
; Count: [ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ] [ 6 ] [ 7 ]

; The 7-Byte Programm.
; Only usable for 16 and 32Bit machines.
; Open up CMD (Win+R, "CMD", ENTER) and type:
; C:\n

; What it does: >SMILE< if you know it =)

Wer daran rumpfuschen will setzt einfach den ASCII Code seines Lieblingszeichens in das xte Byte ein. Wer zuerst rausfindet, was x ist bekommt nen feuchten Händedruck

Doch soll so sein, um User vor schlechten Gewohnheiten zu schützen ^^.

Zitat von Joriktos

Also die neueste Stable-Version ist 3.3.8.1

:

Zitat von Ryan

neuste SciTe Version (3.2.0)

#AutoIt3Wrapper_Run_AU3Check=n

Assign hat wenig Nutzen für normale Projekte. Wieso benutzt du es?

Die Methodik habe ich mir so nicht ersonnen, das war MS. Das Problem ist, das vor dem Erstellen des Buffers in der WinAPI eine Struct erstellt werden muss, die muss nunmal eine feste Länge haben - ob ich da nun eine Zahl oder diese Funktion einsetzte macht zeitlich keinen Unterschied. Oder anders gesagt: Bevor das zeitlich einen Unterschied machen würde, wärst du sowieso schon an der Call-Grenze der Console-Funktion pro Sekunde. Consolenanwendungen sind für LASM sowieso total ineffizient, da viel mehr vorbereitende Funktionen und Konstanten notwendig sind, als bei einem GUI Subsystem.

Zitat von James1337

Es wäre außerdem cool, wenn LASM mit -h oder /? eine kleine Hilfe anzeigen würde und man mit -o nur den Bytecode erhält,

Na wenn ein Helpfile, dann ein externes. Ich versuche mich zZ an der LASM Dll, die man dann um den Bytecode bemühen kann.

Andy:

Einfaches Fallbeispiel ist die (bereits umgesetzte) Funktion ConsoleWrite. Diese nimmt einen DWORD String an - aber wozu soll man mehr Buffer im Kernel bereitstellen als nötig? Das wäre Mumpitz ^^. Deswegen muss vorher die Bytelänge bestimmt werden, denn diesen Wert erwartet auch die WinAPI ^^.

Bei Funktionen die eine Struct benötigen, ist die Bytelänge bereits fest angegeben.

Zitat von Andy

Btw, der Link ist tot, gibt es schon Updates?

Der Download funktioniert auf jeden Fall ^^. Du hast doch garnicht den Link

Lieber einen Plattform-Unspezifischen Compiler. Wenn man es mal auf den Compilerthread bezieht: Es ist ja geplant, dass die Zwischensprache Perseus nicht nur LASM Code auspsucken muss. Sie lässt sich sehr leicht auch dazu bewegen zum Beispiel NASM-Code auszuspucken, der dann auf Linux kompiliert werden kann. Dann wäre AutoIt Plattformunabhängig. (In diese Richtung geht auch der AutoIt -> C Konverter).

Zitat von ohforf

Sieht so aus, als würde hier das Rad neu erfunden, noch dazu in Assembler... *grusel*

So … schreibt man nunmal einen Compiler

Zitat von ohforf

Ich meine so triviale Sachen wie StringLen wurden doch schon 1000 mal geschrieben und veröffentlicht.

Das ist mir nicht bekannt - in der benötigten Form sicher nicht :P. Und AutoIt-Funktionen erst recht nicht.

Die Source-Pakete sind ja nun schon eine ganze Weile raus und nicht wenige haben es bereits getestet. Wäre schön, mal eine Rückmeldung zu bekommen

DEP (Data Execution Prevention) ist ein Feature, das mit WinXPSP2 eingeführt wurde. Es soll das Ausführen von Schadcode dahingehend behindern, dass bestimmte Speicherblöcke unzugänglich gemacht werden. Einige Anwendungen schneiden aber manchmal den geschützten Speicherbereich und crashen dann einfach. Mit dieser Funktion kann DEP abgeschaltet (und auch wieder angeschaltet) werden.

Dann wäre es doch gut den Präfix auf [gelöst] zu ändern

Java und NET sind Bytecode-Sprachen. Aus dem Code wird Bytecode der von einer Virtuellen Maschine ausgeführt wird. Das ist etwas völlig anderes als ein reiner Interpreter und ist verdammt schnell.

Popularitätsindex TIOBE
Benchmarkindex der bekannten Sprachen

AutoIt ist nicht langsam. Und Python soll langsam sein? Dafuq?

AutoIt ist interprtiert, das heißt es ist logischerweise viel langsamer als assemblierte (oder compilierte) Sprachen wie C / BASIC / PASCAL.

Kleinere Benchmarks bestätigen, dass AutoIt an sich tatsächlich etwas schneller geworden ist.

Zwischen X1 und X2 besteht der Unterschied, dass X1 keine tenären Operationen und keinen direkten Struct-Zugriff unterstützt (Andere Sachen wie das fehlende $ sind aber schon in der X1 verarbeitet)
Dateimäßig gibt es keinen Unterschied zwischen X1 und X2 - das ist zwar sinnlos, aber nicht zu ändern. Es sind trotzdem verschiedene Versionen.

Dafür wurde #region erfunden

Links, auf die man als Nichtmitglied nicht zugreifen kann. Deswegen sind die Links hier auch vorhanden .

Aber du kannst sie laden und wir mirroren sie dann - wenns erlaubt ist

EDIT: Die Links sind nichtmal für Mitglieder erreichbar. Anscheinend deshalb auch nicht öffentlich.

Bei OpenGl Problemen immer fragen

Also ich nicht. Au3Check und das neue SciTe (beide mit dabei) kommen perfekt damit klar. Immerhin hat sich bei Au3Check auch was getan in Sachen Fehlerbeschreibung.

Wenn es bei dir einen Error gibt, liegt es daran, dass beim Ausführen auf das alte Au3Check zugegriffen wird (denke ich). Hat man nur die neue Alpha geht alles perfekt. 99%ig

Zitat von name22

praktisch inkompatibel mit dieser Version

Davon merke ich aber nichts [Blockierte Grafik: http://files.overclock.net/images/smilies/graduated.gif]

Wärst du "immer" auf der Website im Beta-Ordner gewesen hättest du die 3.3.9.5 dort gesehen. Sie wurde einfach gelöscht.