Beiträge von DosAmp

    Zitat von Unregistriert

    Morgen,
    falls ihr noch irgendwo eine olle DOS Kiste rumstehen habt und ihr mal ohne teure Onlineverbindung und ohne Crossoverkabel (bzw. ihr habe keins mehr) alte DOS Software die eigentlich eine Onlineverbindung benötigen ala BinkleyTerm etc.. könnt ihr einfach euch das msim und den fossiltreiber x00 für MSDOS downloaden und dann ohne echte Onlineverbindung eure DOS Programme testen.
    Viel Spass dabei!!
    Hier noch die Downloadlinks:
    $KENNENWIRLÄNGSTSCHON
    Funzt wirklich!! Habs grade getestet!!


    Verdammt, Sven. Ein Thread reicht für ein Thema. Und wenn ich genau ein Thread meine, könnte ich den Thread hier gleich in seiner Gesamtheit schließen.

    Zitat von Alex

    Die Frage: wer nicht! :b1:


    Ich, weil ich auch sehr gut mit Vista SP1 (bzw. bald™ SP2) auskomme und mir ohnehin nächstes Jahr ein Laptop mit Windows 7 (ggf. schon SP1) kaufe. Mein testweise installiertes Windows 7 RC hab ich – nach meiner Abmachung mit mir pünktlich nachdem ich HL1 durchgespielt hatte – jetzt wieder gegen ein schnuckliges 64-Bit-Arch getauscht. :D

    Code
    1. http://www.winhistory-forum.net/93399-post17642.html
    2. wget -O input.file $YOUTUBELINK
    3. ffmpeg -i input.file -vn -acodec libmp3lame -aq 2 ${ZIELDATEINAME}.mp3
    (Anm.: -aq –> Audioqualität, äquivalent zum Parameter -V von lame und damit der VBR-Qualitätsstufe)

    Damit musst du zunächst nur noch die URL und den Titelnamen kopierpasten. :>

    Wenn ich Zeit habe, kann ich dir heute nachmittag selbiges mal als einfaches Python-Skript schreiben.

    Hiermit möchte ich den Nachweis für die Urheberschaft der aufpolierten :b1: erbringen und gleichzeitig die Entwurfsstudie für erstere (GIMP-Dateiformat) veröffentlichen (beides im Original schon mal auf Pixelbanane bzw. euda.ath.cx hochgeladen, aber wieder verschwunden).

    Im Übrigen bin ich zur Zwei-Panel-Methode zurückgekehrt – allerdings ist mein Desktop immer noch wesentlich individueller als der eines durchschnittlichen Xubuntu-Benutzers.

    Zitat von Wynton

    Lieg ich da auch mit der vermutung richtig das es egal ist unter Linux welche Arch ich mir schnappe? zb x86_64, sparc oder sonstiges?


    Solange du dich möglichst aus der pythoneigenen Programmbibliothek bedienst und gewisse Spielregeln einhälst (etwa os.path.join zu benutzen, um Ordner und Dateiname zusammenzuschweißen), ist der entstehende Code recht plattformübergreifend – os.path als konkretes Beispiel wird unter Windows NT auf das Modul ntpath verlinkt, unter Unixen dagegen auf posixpath. Das kann ich auch persönlich bestätigen, einige MP3-Skripte hab ich hier sowohl unter Windows und Linux in Betrieb und die einzig angepassten Parameter sind die Dateipfade.

    Python hat schon viel an Bord und wie du siehst, wird auch extern genug nachgebaut, unter Windows etwa in Form in der ActivePython-Distribution (gegenüber dem offiziellen Python-Build für Windows).

    Zitat von YAL

    Ich werf ma python innen Raum. Kann ich sehr empfehlen. Is halt eher weniger hardwarenah...


    Dito:

    Zitat

    <DosAmp> ich würde Wynton ja zu python raten, aber da fällt zumindestens der aspekt "Hardwarenähe" weg<DosAmp> allerdings kann man unter linux eh schwer hardwarenah programmieren, solange man nicht selber module bastelt<pete> Java ist auch nicht gerade Hardwarenah<pete> aber hardwarenahe Programmierung ist eh out<DosAmp> ich hab nichts anderes behauptet<Alex|AK09> euda, wie soll man sonst leds am LPT an und ausschalten :(<pete> dafür gibts Treiber und sowas<DosAmp> treiber bauen und dem ein durchdachtes frontend geben<Alex|AK09> n treiber schreiben um die 8 ausgänge auf High oder Low zu setzen is dann doch etwas overkill :><pete> Wieso das denn?<pete> muss ja nix großes sein<DosAmp> vor allem, da solche routinen immer mal wieder gebraucht werden

    Es hilft nix, wenn du durch Antz oder Aquanox auf mein Stammforum gekommen bist und anonym postest, Svenn (aka prro etc.). Die URL verrät dich.

    Und noch mal werde ich an meinem Windows ME deswegen nicht wie verrückt friemeln – ich habe weiß Gott besseres zu tun –, aber da es ggf. Leute gibt, die sich für das Thema interessieren könnten (auch wenn ich das bezweifele), mach ich mal das Thema auf.

    Ich lasse aus Prinzip UAC stets eingeschaltet und schaue manchmal kopfschüttelnd auf Leute, die ohne Ahnung rigeros UAC ausschalten, sowie Programmierer, die sich nicht an Vorgaben des Betriebssystem-Herstellers halten, die schon spätestens seit Windows XP bestehen, herab.
    Für den Fall, dass man dauernd fehlerhafte Programme ausführen muss, die sich nicht an diese Vorgaben halten, gibt es immer noch den stillen Modus der UAC.

    Ich kenne ebenfalls zumindestens die Bildschirme des reinen Treibers für „originale“ WSS-Systeme – da ich Probleme hatte, die Windows-3.1x-Treiber für die SB16-Emulation meines Omnibooks zu installieren, habe ich einfach andere für die CS4231- aka WSS-Emulation installiert – fluppt. :)

    Die CS4231 ist übrigens auch unter Linux der einzige Weg, Sound an der Kiste zu bekommen, weil die Audio-Implementierung des Neomagic-Chips von der Norm abweicht und snd_nm256 deswegen nichts erkennt.