Beiträge von GrandAdmiralThrawn

    Ich weiß nicht Mal mehr, was es braucht um einen Steam Account zu registrieren (weil das habe ich nur ein einziges Mal gemacht ;) ). eMail Adresse und Rest fake ist möglich? Dann würde ich natürlich einen Fakeacc dafür benutzen. Kann ja auch ein fast leerer Client sein, wenn's nur um Tests geht. F2P Titel gibt's ja auch, um zu sehen ob der Launch ginge. Aber das ist sowieso ungewisse Zukunftsmusik, will hier keine Hoffnungen schüren, die dann nicht zufriedenstellbar sind.

    Also am Client würde ich nicht rumbasteln wollen. Du kannst die Umgebung manipulieren, aber von Steam selbst würde ich die Finger lassen, schon allein des Geldes wegen.

    Ist natürlich ein Risiko dabei, das ist schon klar. Aber keines, daß sich den Leuten bei Valve nicht vernünftig erklären ließe. Aber selbst dann könnte es natürlich gut sein, daß alleine die Modifikation der Files hinreichend ist, um einen Account dauerhaft zu sperren. Da kann man halt nicht viel machen, wo gehobelt wird, fallen Späne. ~95% meiner AAA-Titel brauche ich sowieso nicht mehr. Um einige wenige wäre es halt schade, aber die Indietitel sind mir schon seit Jahren spielerisch wesentlich mehr wert, die würden sich auch leicht rauskopieren und im Extremfall auch zurückkaufen lassen, wenn's wirklich drauf ankommt (sind ja nicht so teuer). ;)


    Allerdings können die meisten Tests modifzierter Binaries offline erfolgen, was das Risiko zumindest etwas reduziert. Wenn sich beim Offlinetest schon herausstellt, daß ich es niemals hinbringen kann, dann ist es nicht Mal nötig, einen Onlinetest zu wagen, wenn das Teil sowieso nicht starten will.

    Eventuell ist ein remirroring hier nicht nötig (so wie im x264 Thread von dir erwähnt). Falls du Platz sparen mußt, kannst das Oral History Panel denke ich weglassen, das lädt so gut wie niemand mehr, soweit ich das bei mir sehe.


    Danke jedenfalls für die langwährende Unterstützung! :)

    Ich sehe auf XP & XP x64 jedenfalls noch nicht alles als verloren an. Die Chancen sind zwar gering, aber ich habe zumindest ein paar Tricks gelernt die letzten Jahre. Wenn Valve nicht zuviele serverseitige Checks einbaut, müßte es möglich sein, auch einen modernen Client auf XP weiter laufen zu lassen. Ich denke dabei an eine Kombination von Microsofts' Application Verifier Tool (um die OS Kernel Version zu faken), Header Hacks auf die Binaries (um die MajorSubsystemVersion und MinorSubsystemVersion Properties auf 5.1/5.2 zu fixieren, alls der AppVerifier failed) und letzten Endes Stub DLL Hacks wie von Oleg Ovcharenko, KawaiiSara, ScavengerSpb und anderen gebaut, um eventuell fehlende WinAPI Calls zu reimplementieren.


    Das größte Problem dabei ist, daß ich meine C++ Fähigkeiten nicht hinreichend schnell vorangetrieben bekomme... :(


    Dazu habe ich einige Bücher geordert, um die Sprache endlich lernen zu können, und nächstes Jahr plane ich die (scheinbar gute) C++ Vorlesung eines Kollegen auf der Arbeit zu belegen, um voran zu kommen, sofern man mich läßt. Aber das wird sich damit wohl eben alles nicht direkt rechtzeitig ausgehen..

    Bei Indietiteln ist es etwas gängiger, daß auf Steams' DRM verzichtet wird. Nun habe ich einen Sauhaufen eben solcher Indietitel, die teilweise mit Produktionsbudgets von weniger als $10.000 gebaut wurden, also echte "Billigsdorferspiele" sind. Die Leute freuen sich meistens schon, wenn ihr Zeug überhaupt jemand spielt und im besten Fall noch kauft, aber das DRM System bauen die meisten nicht mit ein, zur Freude der Nutzer und leider auch mancher Piraten.


    Wenn man natürlich hauptsächlich höherpreisige AAA-Titel kauft, dann wird das DRM fast immer mit an Bord sein. Ich bin da halt ein bißchen zu sehr von meinem spezifischen Fall ausgegangen: Ich habe aktuell knapp 250 Spiele auf Steam, aber ca. 50 davon sind VNs (durch die Natur der Sache fast immer Kleinproduktionen) und ungefähr 40 sind anderweitige kleine Indiespiele. Da sind dann schon einige dabei, die sich legal herauskopieren lassen.


    Xenozid : Deine Aussage, daß im Steam Applikationsordner eine "Fake EXE" liegt, ist irreführend und nicht ganz richtig. Korrekt ist vielmehr, daß beim Einsatz von SteamStub DRM zwar die normale Spiele .exe vorliegt, aber in verschlüsselter Form als "Payload" einer sie umgebenden .exe, also eines umgebenden Wrappers.


    Das kann man sich vorstellen wie ein selbstextrahierendes Archiv, das nach der Extraktion die extrahierte .exe direkt aufruft. Das Konzept ist fast identisch, nur eben "entschlüsselnd" statt "extrahierend". Der SteamStub Wrapper entschlüsselt also den in der .exe befindlichen "Payload" (die originale Spiele .exe eben) im RAM, und führt sie von dort aus. Ein übrigens überraschend schlecht implementierter Schutz. (ICH WILL HIER ENDLICH MEINEN ALTEN ROLLEYES SMILIE ZURÜCK!)


    Daher ist "Fake" irgendwie nicht richtig, weil der echte Programmcode ja drinliegt. Korrekter wäre eine "Steam DRM verschlüsselte .exe", o.ä.


    CryptonNite : Das von dir beobachtete Verhalten liegt am hohen Preis von TLS Handshaking. Das aktuell neueste Protokoll TLS v1.3 soll dahingehend wieder Abhilfe schaffen, um die Last auf Client- und Serverseite zu reduzieren, und die Handshakes wieder schneller zu machen. Hab allerdings selbst noch keinen direkten Vergleich zwischen TLS v1.2 und v1.3 angestrengt, kommt irgendwann Mal. Ich hoffe natürlich, daß es echt was bringt, weil das wär auch für meinen Server gut; 200MHz Pentium PROs haben mit TLS v1.2 Handshaking auch ordentlich zu schuften, es trifft also langsame Clients wie auch Server. ;) Daher bin ich schon recht interessiert an Version 1.3, denn die meisten Browser können das jetzt schon.

    Ich denke die SSE(2) Geschichte legt sich relativ klar dar. So wie sich Nutzer durch die Nutzung von Steam von Valve abhängig gemacht haben, so hat sich Valve gleichsam von Google abhängig gemacht. Wer Google zum Thema Softwareentwicklung ein wenig kennt, der weiß, daß die extrem progressiv sind. Da werden auch voll unterstützte Betriebssysteme rausgeworfen (Beispiel: RedHat Enterprise Linux 6), einfach weil Google ein paar Libraries zu alt sind.


    Valve ist wohl im Rahmen des Steam Clients schon recht stark an Googles' CEF gebunden, ist ja wie gesagt eine Kernkomponente. Als zweite Wahl blieb nur - so wie früher - die Nutzung der lokal installierten MSIE Browserengine. Das ist aber noch katastrophaler, weil ältere Betriebssysteme noch schneller würden rausfliegen müssen. Du kannst ja nicht leicht mehrere IE Engines supporten, das is bei so einer Plattform ein komplettes Chaos. Selbst zwei verschiedene CEF Versionen sind schon problematisch genug.

    :whistling:

    Von "lächerlicher Schutzbehauptung" kann also leider keine Rede sein, auch wenn ich früher selbst geglaubt hatte, daß das ganze nur ein vergessenes Compilerflag wäre. Das SSE2 Problem geht aber eben tiefer, und läßt sich halt nicht so leicht aus der Welt schaffen. So massiv schnell, wie Google die Chromium Engine (und damit das CEF) weiterentwickelt, wäre es für Valve wahrscheinlich mit erheblichem (=unverhälltnismäßigem) Aufwand verbunden, die Engine bei jedem Update zurechtzupatchen, und das nur für ein paar User, aus denen sich im Leben niemals ein Return of Investment ziehen läßt, was den kontinuierlichen Arbeitsaufwand angeht.


    Und (leider?) muß Valve auf einem 18 Jahre alten, vom Hersteller nicht länger unterstützten Betriebssystem erst einmal gar nichts gewährleisten. Das kannst jetzt eigentlich schon nur mehr als Kulanzleistung bewerten.


    Steam ist in erster Linie eben kein "lokaler Gamelauncher", sondern eine Webapplikation. Nur weil manche User das aufgrund ihres Nutzungsverhaltens anders sehen, heißt das nicht, daß es Steam plötzlich zu einer Software macht, die offline zu funktionieren habe. Das war nie die Idee des ganzen Konzepts, das haben nur wir User uns dazugedichtet/-gewünscht. :rolleyes:


    Wennst glaubst, daß SSE2 so leicht aus der Chromium Engine zu patchen wäre, kannst es ja selbst versuchen, Software ist ja quelloffen. Schaut aber danach aus, als würde der explizite SSE2 Code schon ziemlich tief drinstecken, weil bisher hat das niemand geschafft. Vielleicht auch wegen der irren Entwicklungszyklen bei Google nicht. Die Bestrebungen, XP Backports der Engine zu bauen wurden ja auch links und rechts wieder fallen gelassen, weil das scheints in der Maintenance zu viel Aufwand darstellt.


    PS.: Du mußt die Spiele nicht immer cracken! Jene Titel, die kein Steam DRM dabei haben, kannst du einfach 1:1 rauskopieren und ohne Steam starten, macht keinen Unterschied! Dabei umgehst du dann auch keine Kopierschutzlösung, tust also nichts illegales. Ich selber habe einige solche Titel in der Library.

    Der Pentium 4 hat aber schon SSE2, auch in der allerersten Willamette Version. SSE (früher "KNI") gibt's ab dem Katmai Kern, also dem ersten Pentium III. Und das hat auch der Athlon XP.


    Wenn es also am AXP und am P3 nicht rennt, dann wird der Client wohl (wie ich es erwarten würde auf Basis des Chromium Embedded Frameworks) SSE2 erfordern, und nicht nur SSE. Geschichtlich schaut es so aus, daß man das SSE2 Zeug wohl Mal vorübergehend rausgepatched hatte, aber spätere Versionen haben es dann wieder erfordert.


    Ich hab halt keine Kiste online um das zu testen, also keinen P3 oder AXP, aber ich denke es wird wohl SSE2 als Grundvoraussetzung sein.


    Kann nur sein, daß die für Windows XP eingefrorene CEF Version 49.0.2623.110 noch ein rausgepatchtes SSE2 hat, sodaß es auf XP funktioniert mit den alten SSE CPUs, nicht aber auf neueren Betriebssystemen. Ist aber reine Mutmaßung von meiner Seite.

    Ah.. Das SSE2 Requirement haben's manuell rausgepatched, oder seh ich das falsch? Hab' da grade keinen Überblick, weil Steam ging ohne SSE2 auch schon Mal nicht mehr (Google hat SSE2 im Jahre 2015 zur Pflicht für x86 erhoben, auch weil alle 64-bit Chips SSE2 haben, also bei x64 sinnig ). Aktuell geht's auch nur mit SSE? Das wär - wenn wahr - eh ein Haufen Extraarbeit für Valve, weil's die Chromium Engine umschreiben müßten, um SSE2 wegzubekommen. Das is bei denen mehr als nur ein Compilerswitch...


    Wobei, wenn's bei einem Athlon XP (schon wieder) nicht geht, dann wird der SSE2 Code wohl drin sein.

    Wobei der SSE2-Zwang ebenfalls vom CEF (also der Chromium Engine) herrührt, die kompiliert schlicht und ergreifend nicht mehr auf x86 ohne SSE2, der Codepfad ist mittlerweile Pflicht. Feuer am Dach ist für CPUs mit "nur-SSE2" also dann, wenn Google was neueres (SSE3, SSSE3, SSE4.x) zwangsvorschreibt. Das ist weniger eine Entscheidung von Valve.


    Da muß auch wieder gesagt werden, daß solche größeren Programme zig Libraries anderer Entwickler einbinden, teilweise hunderte (XML Parsing, Audio/Video Playback, Netzwerkprotokolle, Mathebibliotheken, Browserengines, GUI Toolkits, whatever), reicht wenn eine Komponente nicht mehr mit XP oder z.B. ohne SSE2 will, da muß der eigentliche Entwickler des Hauptprogramms nicht Mal was dafür können - so auch in diesem Fall, also was SSE* angeht.


    Edit: Ich sehe grade, daß ich in mehrerlei Hinsicht in den Stats nicht mehr vertreten bin. XP x64 ist verschwunden, so auch die 16:10 Auflösung 2560×1600 und meine GeForce GTX Titan Black..

    Onlinepetitionen sind sowieso für nichts? Und selbst wenn da eine Million Leute dafür stimmen würden (und so viele XP User hat die Steam Plattform nicht mehr), wär's einfach wurscht, weil derartige Stimmen kaum Wert besitzen. Onlinepetitionen mit schnell zusammengeklickten Stimmen werden normal eher belächelt, als sonst was.


    Zudem lehnen die meisten modernen Spieler und auch Entwickler die Unterstützung von XP von sich aus ab. Diese Aussage beruht auf Basis meiner Erfahrungen mit den Leuten bei meiner XP-Kompatibilitätshackerei, die ich seit zig Jahren betreibe. Klar gibt es auch Ausnahmen, aber die überwiegende Anzahl der Leute ist der Meinung, daß XP "endlich weg gehört", und daß es bloß keinen softwareseitigen Support mehr dafür geben solle. Ein Gros der User stehen jemandem wir mir, bzw. meinen Bestrebungen sogar offen feindselig gegenüber, weil die Meinung vorherrscht, daß der Support von XP nur unnötige Entwicklungsressourcen binde, die besser in den Support moderner Systeme investiert seien. Dazu kommt dann noch das klassische Security-Totschlagargument.


    Das ist vielleicht in Retroforen anders, aber die stellen eine Minderheit der Steam Userbase, und von denen sind echte XP User eine noch kleinere Minderheit.


    Valve davon zu überzeugen, ein dann 18 Jahre altes (bzw. 14 Jahre bei XP x64) System weiterzupflegen wird nicht funktionieren, davon bin ich überzeugt. Zudem es keinen Fall gibt, wo Valve eingelenkt hätte, Win9x und 2000 gelten als Präzedenz in der Angelegenheit.


    GOG verfolgt da eine gänzlich andere Marktstrategie...


    ...was mir leider alles nichts hilft, wenn es meine Wunschtitel nur bei Steam gibt. ;)

    Sind halt andere Anforderungen, das haben wir in diesem Thread eh schon gesehen. Bis auf den Umstand, daß ich keine AAA Titel spiele (schon ewig nicht) nutze ich Steam aber quasi wie der typische "moderne Steam User". Das is halt was anderes, als HL² aus Steam auskoppeln zu wollen. Wobei das Problem sich stellenweise schon auch mit meinem überschneidet: Ich habe ja auch schon sehr viele bestehende, auf Steam explizit als XP-kompatibel ausgewiesene Titel hier. Jene die an Steam DRM gekoppelt sind, werden dann im Onlinemodus nicht mehr laufen, weil Steam beim Update den Suizid vollführen wird, wie damals auf Win2000.


    btw., es gibt auch noch (tlw. recht neu veröffentlichte!) Spiele, die auf Steam in den Systemvoraussetzungen explizit nur Win98 oder Win2000 fordern. Ist aber absurd, weil dort gar nicht im Steam Kontext installierbar. ;) Die meisten von denen kannst aber auf einer modernen Kiste saugen, und dann einfach auf die Win98 Kiste rüberkopieren und dort starten...


    d.h. mein aktueller Plan ist es, Steam einfach in meiner Win7 VM zu installieren, und die Spiele über den Shared Folder auf's XP x64 rauszusaugen, wo ich sie dann starte oder zu starten versuche.

    Steam ist halt offline relativ tot. Man kann nicht von jedem Nutzer verlangen, daß er seine komplette Gamelibrary runtersaugt und offline wegsichert, bevor er auf die "finale XP Version" umsteigt. Wie auch bei Origin muß so ein Client online bleiben können. Die meisten Game Libraries sind auch so riesig, daß sie gar nicht Mal so leicht gesammelt auf eine 1-2TB Platte passen würden. Mal abgesehen vom irrwitzigen Traffic, den das bedeutet.


    Wenn das nur ein lokales Programm wäre, mit dem man lokal irgendwas macht (z.B. ein Textverarbeitungsprogramm oder ein Musicplayer), najo, da gibt es solche Bestrebungen eh von einigen Entwicklern. 7zip fällt mir da grade ein. Da gibt's solche "letzten Versionen" zu laden, auch dauerhaft.


    Nur bei einem lebenden, permanent in Entwicklung befindlichen Onlineökosystem ist das halt nicht so einfach. Aus meiner Sicht müßte eine "finale XP Version" mindestens die folgende Funktionalität weiter anbieten, um für mich brauchbar zu sein:

    • Shop (Spiele müssen kauf- und als Geschenk verschickbar bleiben)
    • Download (Bestehende wie neu angeschaffte Spiele müssen geladen und aktualisiert werden können)
    • Extern akquirierte Keys (z.B. von Humble Bundle) müssen aktivierbar bleiben
    • Launcher (Spiele auch inkl. modernem Steam DRM müßten laufen)


    Das stellte Valve allerdings vor ein Problem, weil das bedeutet, daß sie serverseitig auf Dauer wohl zweigleisig fahren müssen, und sowas willst du nie, nie, NIEMALS machen, weil das ein Drecksscheißaufwand ist, wenn du einen Application Server zweigleisig auslegen mußt.


    Und das DRM aus allen Games rauspatchen lassen geht auch nicht, denn da werden die Publisher Sturm laufen, die sich auf's Steam DRM verlassen. Bei der Steam DRM Library z.B. ist das schon ein Problem, hier wird mit einem alten Platform Toolset auf NT 5.2 gezielt bei 64-bit, und auf NT 5.1 bei 32-bit. Wenn du jetzt die Entwicklung des Clients auf neuere Entwicklungsumgebungen migrierst, und dabei die XP Platform Toolsets wegläßt, dann kannst du auch keine XP-kompatiblen Steam DRM DLLs mehr kompilieren. Im blödesten Fall kommt dann ein älteres Spiel mit einer zu neuen Steam DRM DLL daher, und startet aufgrunddessen nicht mehr. Und das ist nur ein Beispiel von zig verschiedenen.


    Sicher kann ich dann anfangen, MajorSubsystemVersion und MinorSubsystemVersion im Header der DLL zu patchen und ggf. fehlende Win API Calls per selbstgeschriebener Stub DLL nachreichen (wie ich es tlw. jetzt mache), aber das is doch keine Lösung für normale Spieler.


    Ich weiß jetzt natürlich nicht, wie EA und Ubisoft das genau lösen, oder ob es da clientseitig nicht eh schon Probleme gibt. Hab die zwei schon länger nicht mehr gestartet. Aber es is ned "alles so einfach", wie man sich das oft vorstellt, das muß auch Mal gesagt sein.


    Es kostet einfach Zeit und Geld.:gadget:


    Und Steam als reiner offline Launcher... Wie oben ausgeführt: Das is für mich so nützlich wie ein Firefox als offline Filebrowser. :rolleyes:


    PS: Das neue "rolleyes" Smilie sucked...

    Auch Windows 2000 ist raus, schon länger. Es geht zwar mittels BlackWingCats KernelEx für Win2k auch dort "irgendwie noch", den Client laufen zu lassen, aber das wird in Zukunft sicher nicht einfacher werden.


    Eine Hoffnung könnte ja sein, daß es auch ein KernelEx in der Frühphase für 32-bit XP gibt, das Teile der NT6.0/NT6.1 APIs zurückportiert, vielleicht geht's ja damit. Brauchst aber ein englisches 32-bit XP, ein Projekt für XP x64 wurde irgendwann Mal angekündigt, wird aber wohl nie in die Startlöcher kommen.


    (Ich habe auch einige reine 64-Bit Spiele hier unter Steam auf XP x64 laufen).


    Ein selten aktualisiertes KernelEx wird halt auch keine sichere Dauerlösung darstellen können, zumindest würde ich nicht davon ausgehen.


    Ein finaler, eingefrorener Client a la Origin Legacy für XP und MacOS X 10.7/10.8 wäre natürlich am elegantesten (für die Endbenutzer), aber denkt Mal nach: Hat es den für Win9x gegeben? Hat es den für Windows 2000 gegeben? Nein!


    Also wird es ihn wohl auch für XP nicht geben.


    Abschließend sei angemerkt, daß Ubisoft den separaten XP Client nicht mehr führt, man [weist lediglich darauf hin], daß man seine bestehende Version weiter nutzen könne, aber man bietet keine XP-kompatible mehr zum Download an:

    As Microsoft has officially ended support for Windows XP, newer versions of Uplay PC are not compatible with this operating system.

    If you have an older version of Uplay PC installed on your Windows XP machine, you will still be able to run it and the games that support Windows XP, but you won't be able to update Uplay PC and benefit from its newest features.


    EAs' [Origin Webseite] hingegen äußert sich bei Besuch von XP x64 so:

    Looks like your computer is running a operating system we no longer support, but you can still download and play your games using an older version of Origin.

    For Windows XP or Vista, click here to download.
    For Mac OSX 10.7 or 10.8, click here to download.


    Pervers, daß ausgerechnet EA den besten XP Support unter den "großen" liefert. GOGs' Galaxy Client is ja auch tot auf XP, aber bei GOG kann man ja wählen, ob man den überhaupt will, weglassen soll auf ewig eine Option bleiben, so wie ich es verstehe.

    Dazu kann ich jetzt nichts sagen, weil ich keine solche Liste kenne, aber selbst Spiele die NACH dem Win7 Release veröffentlicht worden sind (auch Titel aus 2017 und 2018), die auf XP laufen, können weiterhin funktionieren, wenn sie kein Steam DRM nutzen.


    Also das habe ich tatsächlich erfolgreich getestet, in mehreren Fällen. Leider ist das nicht vorab erkennbar, man muß halt Steam beenden (ggf. auch das Spiel von der steam_api*.dll trennen) und danach versuchen, den Titel durch direkten Aufruf der entsprechenden .exe zu starten. Kommt das Spiel dann normal hoch, hat es keinerlei Steam DRM und kann einfach ausgekoppelt werden. Ist natürlich fallweise zu testen, und nicht auf Onlinegames anwendbar, die Steam für Ihre Updates brauchen, um zu den Servern verbinden zu können (Ein solches Beispiel: Mechwarrior Online*). Hier könnte man Steam von innerhalb einer Win7+ VM die Updates direkt in den Host Folder auf XP saugen lassen, und das Spiel danach auf XP aufrufen.


    *Ist mittlerweile btw. 64-bit-only, und läuft daher nur mehr auf XP x64, nicht auf 32-bit XP.

    Jo klar, und du bist nicht (ganz) alleine, aber du bist ggf. vermarktungstechnisch insignifikant, genauso wie ich auch. ;) Wenn die Entwicklungs- und Testzeit für eine frozen XP Version von Steam (nur die Entwicklung & QA, auch wenn kein Support drauf gegeben wird) mehr Geld ausmacht, als was Valve an Gewinnmargen durch die Sales auf XP abgreift, dann wird das einfach nicht passieren, Punkt. Genau genommen wird es sogar weit mehr an Gewinn sein müssen als nur das, weil sonst heben die wohl keinen Finger für irgendwelche kleinen Butterbrote.


    Man müßte Valve also glaubhaft verklickern, daß sich realer Profit auf der Plattform machen läßt.


    Weiterhin "böse aus dem anderen Eck gefragt", was sagst du, wenn ich als Valve sage: "Ok, wir können das schon machen, aber kannst du uns dann zweistellige Millionenprofitmargen pro Jahr auf der Plattform garantieren über die nächsten 3-5 Jahre?"


    "Beibehalten" wird nicht so simpel, dazu brauchst du auch kompatible, serverseitige Interfaces, NICHT vergessen! Steam ist in erster Linie eine Webapp!

    Nach bisherig gesammelten Aussagen soll es keinen speziellen XP Client geben, so wie bei Origin oder UPlay zu sehen. Was den Offlinemodus angeht, dazu kann ich aus eigener Erfahrung nichts sagen. Wäre für mich persönlich aber unbrauchbar, ich will ja auch neue (und alte), XP-kompatible Spiele kaufen und saugen auf der Plattform, wenn GOG den Titel mal wieder ned hat.


    Auch andere Funktionalitäten wie die Cards sind nice (weil man so etwas Cashback kriegen kann). Funzt natürlich nur online.


    Mal schaun, inwiefern Valve noch etwas macht, aber wenn aus der Usergemeinde kein nennenswertes Echo kommt, wird man XP einfach fallen lassen, vermute ich jetzt persönlich. Weil wo kein gesicherter Absatzmarkt, da keine Investition?!

    UPS, DHL and Fedex are all *very* expensive, especially as the package gets heavier and larger.


    The cheapest in my experience is the regular United States Postal Service (known as "USPS"). Their international shipping rates from (s)lowest to highest / most expensive:

    • First-Class Package International Service (never used it)
    • Priority Mail International (~2 weeks)
    • Priority Mail Express International (~1 week)
    • Global Express Guaranteed (never used it, supposedly under 5 days)


    For a mainboard you should get away with less than $50 USD with one of the Priority Mail options.