Wenn ich den Temp-Ordner ändern möchte, der kurzfristig zwischengespeicherte Dateien aufnehmen soll, wird der voreingestellte Ordner mit "%USERPROFILE%\AppData\Local\Temp" angegeben. Man weiß also nicht, welcher Pfad C:\tatsächlicher Pfad da gemeint ist. Das ist beispielsweise notwendig, wenn man im Öffnen Dialog eines Programmes oder einer Website eine Datei spezifizieren muss. Dann muss man sich ausgehend von C:\ (oder Systemplatte) über den tatsächlichen Pfad zur Datei durchklicken. Wieso also muss es hier eine so kryptische Angabe "%USERPROFILE%" geben, zu der man erst mal die Übersetzung suchen muss. In einer deutschen Bedienoberfläche benutzt man (hoffentlich) auch nicht zwischendurch Arabisch, zu dem man sich die Übersetzung suchen muss. Wer kann mich mit dem Sinn erleuchten, der diese Angabe bei der Lokalisierung des Temp Ordners statt dessen tatsächlichem Pfad unverzichtbar macht?
Damit der phoese Admin in seinen Skripten deine Dateien einfacher loeschen kann: del /q/s "%USERPROFILE%\Wichtige Dateien" Wozu sonst? Wenn es dich stoert, dann trag halt ein Verzeichnis deiner Wahl ein...
Folfgang schrieb: > %USERPROFILE%\AppData\Local\Temp" angegeben. Man weiß also nicht, > welcher Pfad C:\tatsächlicher Pfad da gemeint ist. Einfach %USERPROFILE%\AppData\Local\Temp in der Explorer-Adresszeile eintippen/reinkopieren - und schon weißt du es. > Wer kann mich mit dem Sinn erleuchten, der diese Angabe bei der > Lokalisierung des Temp Ordners statt dessen tatsächlichem Pfad > unverzichtbar macht? So hat jeder User auf dem PC seinen eigenen persönlichen Temp-Ordner. Löse Dich mal von dem Gedanken, Windows sei ein Single-User-System.
Folfgang schrieb: > Man weiß also nicht, welcher Pfad C:\tatsächlicher Pfad da gemeint ist. Den Wert der Environment-Variablen USERPROFILE bekommt man auf die gleiche Weise raus, mit der man TEMP in "%USERPROFILE%\AppData\Local\Temp" übersetzt bekommt. In beiden Fällen empfiehlt es sich nicht, das ohne diesen Weg abzukürzen, weil es einem dann in bestimmten Umgebungen um die Ohren fliegt.
Folfgang schrieb: > Wieso also muss es hier eine so kryptische Angabe "%USERPROFILE%" geben, > zu der man erst mal die Übersetzung suchen muss. Weil das nicht unbedingt auf C sein muss, zB. in einer Domänenumgebung auf einem Netzwerklaufwerk.
Ich finde das eigentlich ziemlich clever gelöst (nach vielen langen Jahren). So kann es den Programmen relativ egal sein, wo das Profil konkret liegt. Die Pfade funktionieren immer, so lange das Betriebssystem an den Ordner heran kommt. Das ist super praktisch, z.B. wenn man sein Profil aus Platzgründen auf einem anderen Laufwerk oder im LAN liegen hat. Oder vielleicht sogar das Laufwerk wechseln möchte, ohne sich alles zu zerschießen.
Benutze doch einfach %USERPROFILE%. z.b. im Explorer in die Adressleiste eingeben oder im cmd cd %USERPROFILE% nutzen. Oder im Dateiöffnen Diaglog %USERPROFILE% eingeben.
Rüdiger B. schrieb: > Benutze doch einfach %USERPROFILE%. > z.b. im Explorer in die Adressleiste eingeben oder im cmd cd > %USERPROFILE% > nutzen. Oder im Dateiöffnen Diaglog %USERPROFILE% eingeben. Damit kommt er tatsächlich zum temp-Ordner? Wirklich? ;-)
Folfgang schrieb: > der diese Angabe bei der > Lokalisierung des Temp Ordners statt dessen tatsächlichem Pfad > unverzichtbar macht? Weil dein USERPROFILE ein anderes ist, als meins.
Folfgang schrieb: > "%USERPROFILE%\AppData\Local\Temp" Das ist ein sogenannte Platzhalter. Den setzt Windows automatisch. Er bedeutet das der selbe Aufruf von einen Programm, die Temp-Daten immer in den Temp-ordner des AKTIVEN !!! Users schreibt. Du kannst die Verweise sogar ändern : Systemeigenschaften -> Reiter erweitert -> Umgebungsvariblen. Mit Script für Admins hat das sehr wenig zu tun, außer der Admin nutzt das in einer Batch-Datei wie z.b. die Winstart.bat . Als Programmierer ist das aber für mich wichtig. Der User bekommt nämlich nur Schreibrechte in SEINEN Ordner. Also darf ich den "richtigen" Ordner nicht direkt ansprechen. Ergo über die Umgebungsvariablen. Sollte die Ordner direkt angesprochen werden für mehre User, so muss das im Installationsscript für das Installationsprogramm hinterlegt werden. Der User wird dann oft gefragt : Für mich o. für alle. !!
Wenn man nur das Temp-Verzeichnis will, reicht %temp% Es gibt noch einige andere, die nützlich sein können. U.a. %programdata%, %appdata%, %systemroot% und %programfiles%.
Eiermeier schrieb: > Es gibt noch einige andere, die nützlich sein können. U.a. > %programdata%, %appdata%, %systemroot% und %programfiles%. Wo dann aber ein normaler Anwender auch etwas blöd davorsteht, weil die die echten, englischen Namen des Filesystems haben und nicht die lokalisierten, die man im Fileexplorer bzw. Open-Dialog sieht (also zB. C:\\Users statt C:\\Benutzer).
Folfgang schrieb: > Wenn ich den Temp-Ordner ändern möchte, der kurzfristig > zwischengespeicherte Dateien aufnehmen soll, wird der voreingestellte > Ordner mit "%USERPROFILE%\AppData\Local\Temp" angegeben. Man weiß also > nicht, welcher Pfad C:\tatsächlicher Pfad da gemeint ist. Doch, klar weiß man das. Man muss halt bloß die Umgebungsvariable %USERPROFILE% expandieren. > Wer kann mich mit dem Sinn erleuchten, der diese Angabe bei der > Lokalisierung des Temp Ordners statt dessen tatsächlichem Pfad > unverzichtbar macht? Weil man den Inhalt von %USERPROFILE% auch ändern können will. Z.b. ist eine übliche Anwendung dafür: das System kommt auf C:, alle Userdaten auf D:. Oder eine Freigabe auf einem Fileserver/NAS... All das geht relativ schmerzlos dadurch, dass eben %USERPROFILE% variabel ist und halt jeder (und jedes Programm) jederzeit erfragen kann, was der aktuelle Inhalt dieser Variable ist.
Georg A. schrieb: > Wo dann aber ein normaler Anwender auch etwas blöd davorsteht, weil die > die echten, englischen Namen des Filesystems haben und nicht die > lokalisierten, die man im Fileexplorer bzw. Open-Dialog sieht (also zB. > C:\\Users statt C:\\Benutzer). Ist aber egal. ;) Dann wird das halt weiter gelinkt. Zwar nicht die feine englische Art aber funktioniert. Diese Verlinkten Verzeichnisse mit den deutschen Namen kotzen mich eh regelmäßig an, wenn ich ein System warten muss.
btw... bei Linux wäre das: ~ Übrigens kann Folfgang froh sein das er überhaupt ein auf Deutsch übersetztes Betriebssystem hat. Das kann nicht jede Sprache von sich behaupten. ;-)
Rene K. schrieb: > Übrigens kann Folfgang froh sein das er überhaupt ein auf Deutsch > übersetztes Betriebssystem hat. Das kann nicht jede Sprache von sich > behaupten. ;-) JA, aber MS hat die schlechte Angewohnheit das bis zum Exzess durchzuziehen, und auch in die deutsche Sprache integrierte Worte zu übersetzen. JEDER Deutsche weiß was Pictures sind, und eine document zu übersetzen ist einfach Schwachsinn. Aber ich rege mich auch über deutsche Formeln in Excel auf, als von da her......
Schlaumaier schrieb: > JEDER Deutsche weiß was Pictures sind Sicher? Es gibt auch Leute die bei "Sale" an den Fluß denken :-)
loeti2 schrieb: > Sicher? Es gibt auch Leute die bei "Sale" an den Fluß denken :-) Aber die Deutschen die ich meine haben ein Handy und machen Pitures von ihren Fast-Food. ;) Und deine Leute denken nur falsch weil sie in Rechtschreibung noch schlechter sind als ich schlampig. die sAAle. wird mit 2 A geschrieben. https://de.wikipedia.org/wiki/Saale Weiß sogar ich als Nicht OSSI ;)
Schlaumaier schrieb: > Aber ich rege mich auch über deutsche Formeln in Excel auf Hier kann gevoted werden: https://feedbackportal.microsoft.com/feedback/idea/3cfd5580-162e-ec11-b6e6-000d3a177375
Die schlechten Programmierer erkennt man übrigens daran, dass sie immer feste Pfade verwenden und die Umgebungsvariablen nicht nutzen.
Eiermeier schrieb: > Wenn man nur das Temp-Verzeichnis will, reicht %temp% > > Es gibt noch einige andere, die nützlich sein können. U.a. > %programdata%, %appdata%, %systemroot% und %programfiles%. Ich weiß jetzt nicht warum hier so getan wird als ob das Geheimwissen wäre. Variablennamen die von Vater zu Sohn vererbt werden? Nö. Umgebungsvariablen gibt es bei Microsoft seit 1982, seit den Zeiten von MS DOS / PC DOS 2.0. Geklaut hat es Microsoft natürlich von Unix. Konsole aufmachen. Wenn alte COMMAND- oder CMD-Kommandozeile:
1 | set |
eingeben. Wenn Powershell dann
1 | dir env: |
eingeben.
Hannes J. schrieb: > Ich weiß jetzt nicht warum hier so getan wird als ob das Geheimwissen > wäre. Wer tut denn so? Die Umgebungsvariablen wurden schon oft genug genannt. Was ist jetzt der Unterschied zu deiner Erwähnung der Umgebungsvariablen?
Hannes J. schrieb: > Ich weiß jetzt nicht warum hier so getan wird als ob das Geheimwissen > wäre. Das meiste Geheimwissen dieser Welt ist nicht geheim. Es ist nur verloren gegangen, weil neu modische Technologien dieses Wissen nicht mehr benötigen. Schau mal History-Channel dann weißt du was ich meine. Wenn der TO Kicad benutzen würde, wüsste er was das %pfad% ist. Der normale User klickt auf Bilder mit den Ordner-Symbol und weiß nicht einmal das das nur ein "verlinktes" Verzeichnis ist. Es wird halt für die User immer einfacher gemacht, was teilweise ausartet. Siehe Win-11 wo man bei "Rechte Maustaste, erst mal unten hin klicken muss, um Umbenennen zu finden. (Mir fällt der Name des Menüpunkt akt. nicht ein, habe vor 3 Tagen das erste mal mich durch Win-11 gefressen im Schnelldurchgang). Ich bin noch mit Windows 2.0 (kein Tippfehler) und DOS 3.11 aufgewachsen, mit Batch-Programmierung. Da waren so Sachen halt das "Täglich Brot".
(prx) A. K. schrieb: > Folfgang schrieb: >> Man weiß also nicht, welcher Pfad C:\tatsächlicher Pfad da gemeint ist. > > Den Wert der Environment-Variablen USERPROFILE bekommt man auf die > gleiche Weise raus, mit der man TEMP in > "%USERPROFILE%\AppData\Local\Temp" übersetzt bekommt. In beiden Fällen > empfiehlt es sich nicht, das ohne diesen Weg abzukürzen, weil es einem > dann in bestimmten Umgebungen um die Ohren fliegt. Heißt das, dass mir die Umgebung um die Ohren fliegt, wenn ich die Temp Systemvariable "%USERPROFILE%\AppData\Local\Temp" (auf der System SSD) durch G:\Temp auf einer HDD ersetzte? Ist das dann eine solche unzulässige Abkürzung? Wenn das nicht geht, wie kann ich dann dafür sorgen, dass die zwischengespeicherten Temp-Dateien - und nur diese - nicht auf meiner SSD, sondern auf meiner HDD landen?
Eine unzulässige Abkürzung ist es, implizit in nicht ausschliesslich persönlich von dir genutzten Anwendungen von bestimmten Werten in diesen Umgebungsvariablen auszugehen. Wie Du diese Umgebungsvariable änderst, findet sich im Web. Beispielsweise https://www.howtogeek.com/285710/how-to-move-windows-temporary-folders-to-another-drive/
Folfgang schrieb: > Heißt das, dass mir die Umgebung um die Ohren fliegt, wenn ich die Temp > Systemvariable "%USERPROFILE%\AppData\Local\Temp" (auf der System SSD) > durch G:\Temp auf einer HDD ersetzte? Nach einen Neustart bei TEMP mit Sicherheit NICHT. Einige Miese Programmierer wie MS bei VB muss man noch interne etwas nachbessern (Projekt laden, und dann wieder speichern, damit die Temp-Dateien neu initialisiert werden) aber das sind Kleinigkeiten. Und treten nur auf wenn du den alten TEMP-Ordner löscht. ABER. Grundsätzlich sind Systemvariablen Genau dafür da, das man es ändern KANN, OHNE das es irgend ein Stress gibt. Nur gegen schlechte Programmierer mit Direktzugriffen, statt die environment abzufragen hilft nun mal NIX. SO macht man das richtig. Private sql_dbpath As String = System.IO.Path.Combine(Application.StartupPath, "Datenbank.db") Private sql_conn As New SQLiteConnection("Data Source=" & sql_dbpath & ";") Egal wo der User das prg. installiert, der zugriff ist immer richtig. Und für Temp-Dateien. Textbox_1.text = Path.GetTempPath(); Gibt immer dein Temp_path aus der Umgebung-Variable zurück. Mache ich das also richtig, steht beim nächsten Neustart den Programms in der Textbox_1 "G:\Temp " nach deinen Beispiel. Aber programmieren ist wie eine Grippemittel. Macht man es gleich richtig, verdient man nix mit Updates und Service-Vertrag. ;)
Folfgang schrieb: > Heißt das, dass mir die Umgebung um die Ohren fliegt, wenn ich die Temp > Systemvariable "%USERPROFILE%\AppData\Local\Temp" (auf der System SSD) > durch G:\Temp auf einer HDD ersetzte? Ist das dann eine solche > unzulässige Abkürzung? Es ist unzulässig, denn du willst ja nicht das ganze Benutzerprofil verschieben, sondern nur das Temp-Verzeichnis. Dementsprechend wäre es absolut hirnrissiger Unsinn, die für das Profil zuständige Variable zu ändern. Nein, da ändert man natürlich nur %tmp% und %temp%, denn die sind für das Temp-Verzeichnis zuständig. Übrigens enthalten die im "Normalzustand" auch einen Pfad zum Temp-Verzeichnis, bei dem %USERPROFILE% bereits aufgelöst wurde...
c-hater schrieb: > Es ist unzulässig, denn du willst ja nicht das ganze Benutzerprofil > verschieben, sondern nur das Temp-Verzeichnis. Quatsch. User : Paul User : Peter Global Public Er lenkt die Varible TEMP !!!! auf einen anderen Ordner um. Bei Paul c:\users\PAUL\AppData\Local\Temp <- alter Ordner auf neuer Ordner G:\Temp <- Erlaubt wenn auch nicht sehr klug, da sich dann aller Müll ALLER User darin sammelt. Klug wäre G:\Temp\%USERPROFILE%\ was bei PAUL in G:\TEMP\PAUL <- Temp-Ordner für Paul auf der Platte G. umgewandelt wird vom System. Das kann man mit allen Usern machen. Ich z.b. habe den TEMP-Ordner von FF auf eine alte 128 GB SSD umgelenkt. Grund : Temp-Müll juckt mich nicht, und die alte Platte ist mit 15 Euro zu ersetzen. ;)
Schlaumaier schrieb: > Bei Paul > c:\users\PAUL\AppData\Local\Temp <- alter Ordner > > auf neuer Ordner > > G:\Temp <- Erlaubt wenn auch nicht sehr klug, da sich dann aller Müll > ALLER User darin sammelt. Und wen stört das? > Klug wäre G:\Temp\%USERPROFILE%\ Das ganz sicher nicht, weil %USERPROFILE% typisch ein absoluter Pfad ist. G:\TEMP\C:\Users\Paul kommt echt nicht gut, weil illegaler Pfadname. ->Exception Also, wenn man schon aus irgendwelchen Gründen auf per User getrennte Temp-Verzeichnisse besteht, dann ist man tatsächlich klug und macht das natürlich eher nach dem Schema: G:\Temp\%USERNAME%\
c-hater schrieb: > Das ganz sicher nicht, weil %USERPROFILE% typisch ein absoluter Pfad > ist. Ist es NICHT Start -> Systemeinstellung-> System -> erweitere Einstellung -> Umgebungsvarible. Kling mal auf TEMP da ist der Pfad angeben. %USERPROFILE% <- ist ein Platzhalter für den ANGEMELDETEN USER. Und nix anders. Genauso wie 1983 %1 für DOS bei Batch-Funktionen.
Schlaumaier schrieb: > %USERPROFILE% <- ist ein Platzhalter für den ANGEMELDETEN USER. Und nix > anders. Also, bei jedem mir bekannten Windows sagt "set" an der Kommandozeile was anderes. Und auch die für Environmentvariablen zuständige Dotnet-Objekt System.Environment sagt was anderes und (wenig überraschend) auch die Funktion GetEnvironmentStrings in der kernel.dll (also Win32-API). All die sagen übereinstimmend: %USERPROFILE% wird aufgelöst zum absoluten Pfad des Homeverzeichnisses des Users, %USERNAME% hingegen zum Anmeldenamen des Users. Kurzfassung: du hast keine Ahnung. Aber davon eine ganze Menge.
Wieso klickst du nicht einfach was ich dir gesagt habe. Da steht der Pfad richtig doch drin. Ich mag keine Ahnung haben, aber lesen kann ich.
c-hater schrieb: > All die sagen übereinstimmend: %USERPROFILE% wird aufgelöst zum > absoluten Pfad des Homeverzeichnisses des Users, Diese Aussage ist sogar grob eingeschränkt richtig. Du lenkst ja nur EIN Teil des Ordners des " zum absoluten Pfad des Homeverzeichnisses des Users" um und NICHT den ganzen Pfad. ABER. Ein PFAD ist immer KOMPLETT. Und %USERPROFILE% übergibt NUR den NAMEN des User-Profil an den Pfad. Als PLATZHALTER. !!! Einfach gesagt, ich ändere NICHT das Home-Verzeichnis des Users (das geht nicht so einfach) sondern ich ändere ein UNTER-TEIL des Verzeichnis. Und zwar alle Teile die ich in den Umgebungsvariablen ändern DARF + KANN. Einfach gesagt, ein Teil MUSS auf C: Bleiben.
Schlaumaier schrieb: > Wieso klickst du nicht einfach was ich dir gesagt habe. > > Da steht der Pfad richtig doch drin. Ja, das steht da ja am Anfang des Pfads und wird mit dann z.b. mit Appdata\Local\temp ergänzt. Was natürlich den korrekten Pfad ergibt, also z.B.: C:\Users\Paul\Appdata\Local\temp Wenn man aber so idiotisch ist, einen Pfad wie von dir vorgeschlagen zu verwenden: >>> Klug wäre G:\Temp\%USERPROFILE%\ Dann würde halt herauskommen: G:\TEMP\C:\Users\Paul Und das ist nunmal ein illegaler Pfad. Also Schwachsinn zum Kubik!
c-hater schrieb: > Und das ist nunmal ein illegaler Pfad. Also Schwachsinn zum Kubik! Dann dreh ihn halt rum. Ich ändere so ein Mist nicht. Die Auslagerungsdatei hat viel mehr Zugriffe als die TEMP-Ordner. Und legt man die auf eine "Platte-mit-Motor" ist das System viel viel langsamer. Ergo. Backup Machen und gut ist.
Schlaumaier schrieb: > Aber ich rege mich auch über deutsche Formeln in Excel auf, als von da > her...... Wenn die dabei wenigstens das strunzdämliche ARCSINHYP() etc aufgegeben hätten, dann wäre es immerhin ein Fortschritt.
:
Bearbeitet durch User
Schlaumaier schrieb: > Ich bin noch mit Windows 2.0 (kein Tippfehler) und DOS 3.11 > aufgewachsen, mit Batch-Programmierung. Da waren so Sachen halt das > "Täglich Brot". Du meinst mit "mit Windows 2.0 aufgewachsen" sicher "es war zu meiner Zeit verfügbar, aber ich habe es nicht benutzt". Windows 2.0 war damals noch komplett im Real Mode. Der Speicher war knapp und Windows 2.0 hat, außer Speicherplatz zu fressen nichts gebracht. Das änderte sich erst mit Windows 3.0 und dem Protected Mode, also Standard Mode von Windows. Da war der Speicher erweiterbar und die Vorteile von Windows überwogen.
Nano schrieb: > Du meinst mit "mit Windows 2.0 aufgewachsen" sicher "es war zu meiner > Zeit verfügbar, aber ich habe es nicht benutzt". Ich meinte es war auf den Schulungs-Rechner drauf und ich musste damit umgehen können, genau so wie ich COBOL gelernt habe damals. Ich muss aber zugeben ich bräuchte einige Std. bevor ich meine Gehirnzellen überreden kann, das alte Wissen was ich danach nie gebraucht habe, wieder frei zu geben. ;) Percy N. schrieb: > Schlaumaier schrieb: >> DOS 3.11 > > Wann und wo soll es das gegeben haben? https://de.wikipedia.org/wiki/MS-DOS Zitat : MS-DOS 3.1 März 1985 erstmals mit Netzwerkunterstützung; Speichernutzung oberhalb 640 KB War das erste OS mit den ich gezockt habe auf den PC. Damals noch bedeutet schlechter als auf mein C=64. Die Aussage in Wiki ist aber nicht wirklich richtig. Man brauchte himem.sys um bis 1 MB zu kommen. Mit den kostenpflichtigen Qemm konnte man aber sogar bis 4 MB kommen (wenn man es sich leisten konnte, Speicher war damals sauteuer). Ist Finanziell und leistungsmäßig etwas das gleich wie heutzeutage 64 GB der teuersten Riegel. ;) Richtig lange hatte ich einige Jahre später dos 3.11 danach dann Dos 5.0 Es galt damals schon die Regel. Niemals was installieren was bei MS eine Gerade Versions-Nr. hat. Win-98 war die einige halbwegs brauchbare Ausnahme, bis heute.
Schlaumaier schrieb: > Richtig lange hatte ich einige Jahre später dos 3.11 Und nach genau dessen Urspring und Vertriebszeitraum hatte ich gefragt. Es gab zwar ein OEM-DOS 3.21, aber 3.11 ist zumindest mir nur als Windows-Versionsnummer geläufig. Schlaumaier schrieb: > danach dann Dos 5.0 Dann hast Du 4.01 übersprungen, die letzte Version, die noch mit GWBASIC ausgeliefert wurde vor später QBASIC. Und erst ab 5.0D gab es einen netten Editor (der auf QBASIC aufbaute) .
Schlaumaier schrieb: > Nano schrieb: >> Du meinst mit "mit Windows 2.0 aufgewachsen" sicher "es war zu meiner >> Zeit verfügbar, aber ich habe es nicht benutzt". > > Ich meinte es war auf den Schulungs-Rechner drauf und ich musste damit > umgehen können, genau so wie ich COBOL gelernt habe damals. Bei welcher Schulung war ein Umgang mit Windows 2.0 Pflicht? Wäre es vielleicht denkbar, dass du das mit MS Word verwechselst? Davon gab es nämlich eine DOS Version und die wurde durchaus benutzt und Kurse gab es dazu auch. > Zitat : MS-DOS 3.1 März 1985 erstmals mit Netzwerkunterstützung; > Speichernutzung oberhalb 640 KB > > War das erste OS mit den ich gezockt habe auf den PC. Damals noch > bedeutet schlechter als auf mein C=64. > Die Aussage in Wiki ist aber nicht wirklich richtig. Man brauchte > himem.sys um bis 1 MB zu kommen. HIMEM.SYS gab es bei MS-DOS erst ab Version 5.0. Und die Aussage in der Wiki scheint diesbezüglich auch richtig, denn die bezieht sich auf MS-DOS 5.0, was HIMEM.SYS ja mitlieferte. > Mit den kostenpflichtigen Qemm konnte > man aber sogar bis 4 MB kommen (wenn man es sich leisten konnte, > Speicher war damals sauteuer). Ist Finanziell und leistungsmäßig etwas > das gleich wie heutzeutage 64 GB der teuersten Riegel. ;) Ja, mit QEMM war das auch vor MS-DOS 5.0 möglich, wenn man einen passenden Rechner dafür hatte und sich QEMM extra von Quarterdeck kaufte. Dazu benötigte man aber zwingend eine MS-DOS Version 3.30 oder höher. Mit MS-DOS 3.1 ging das nicht.
Nano schrieb: > und sich QEMM extra von Quarterdeck kaufte. Und mit DESQview sogar schon mehrere DOS Windows ohne Windows hatte.
(prx) A. K. schrieb: > Und mit DESQview sogar schon mehrere DOS Windows ohne Windows hatte. Das hatte ich nie. Irgendwann nach GWbasic habe ich dann mit "Dos-Fenstern" unter Power-Basic (Kostenpflichtig) angefangen. Für GW-Basic hatte ich sogar einen Compiler. Und mein ersten Semi-Professionelles Prg. geschrieben damit. Wurde aber wegen der Geringen Verbreitung von PC's nur ca. 500 x Kopiert.
Schlaumaier schrieb: > Irgendwann nach GWbasic habe ich dann mit "Dos-Fenstern" unter > Power-Basic (Kostenpflichtig) angefangen. Ab DOS 6.0 (oder schon 5.0 ?) gehörte SHELL zum Lueferumfang, das tatsächlich eine Art Fenster zur Verfügung stellte. Schlaumaier schrieb: > Für GW-Basic hatte ich sogar einen Compiler. Der hieß aber vermutlich nicht GWBASIC, sondern zB BASCOM.
Percy N. schrieb: > Der hieß aber vermutlich nicht GWBASIC, sondern zB BASCOM. BASCOM ist ein Crosscompiler für µC, z.B. AVR
Paul schrieb: > Percy N. schrieb: > >> Der hieß aber vermutlich nicht GWBASIC, sondern zB BASCOM. > > BASCOM ist ein Crosscompiler für µC, z.B. AVR Wir reden hier über die Zeit vor dem Krieg; da gab es noch nix AVR-Compiler aus dem RGW-Gebiet. https://de.m.wikipedia.org/wiki/BASCOM_(Microsoft)
:
Bearbeitet durch User
Percy N. schrieb: > Der hieß aber vermutlich nicht GWBASIC, sondern zB BASCOM. Vermutlich. Kann mich echt nicht erinnern. Aber ich weiß 1000000 % das ich NIEMALS einen Quellcode ausgeliefert habe. Hab gerade bei Wiki nachgeschaut. Bascom brauchte einen Run-Time. Und eine Runtime habe ich mit ausgeliefert DAS weiß ich noch. Bei "Basrun.exe" o.s.ä. dämmert mir was. Man das war mein erstes professionelles ausgelieferte Prg.. Mnn lang lang ist her. z.b. Musste ich in GWBasic die Datenbank + den Zugriff noch selber schreiben. Was für ein Elend. Index-Relationaler Zugriff. Grausig damals. Nix so schön wie heute, wo ich einfach eine sqlite DB anbinde. ;) Bin dann ganz schnell zu Powerbasic gewechselt., weil die Firma die Produktpalette erweitert und GW-Basic superschnell an seine Grenzen kann. http://www.powerbasic.de/index.althtm Ich fasse es nicht, das Zeug gibts sogar noch für Win-10 !?!?! Wow da kommen echt nostalgische Gefühle auf. ;)
Schlaumaier schrieb: > Hab gerade bei Wiki nachgeschaut. Bascom brauchte einen Run-Time. Und > eine Runtime habe ich mit ausgeliefert DAS weiß ich noch. > Bei "Basrun.exe" o.s.ä. dämmert mir was. Man das war mein erstes > professionelles ausgelieferte Prg.. Mnn lang lang ist her. Vorsicht, es,gab auch Versuonen, die stabd-alone-Kompilate produzierten; ebenso war bei Version 7 O PDS das ISAM-Modul wahlweise integrierbar oder separat zu laden. Ja, wirklich recht lange her. Power BASIC wurde btw zunächst als,TURBOBASIC von Borland vertrieben. Später hat Borland BASIC aufgegeben und MS sich von Pascal getrennt.
Percy N. schrieb: > Vorsicht, es,gab auch Versuonen, die stabd-alone-Kompilate produzierten; > ebenso war bei Version 7 O Mag sein. Aber ich hatte ne Runtime dabei das weiß ich noch. Powerbasic lief OHNE. Und da war auch das ISAM-Modul für den Datenbakzugriff drin. Lief bedeutend schneller als meine Version. ;)
Schlaumaier schrieb: > Mag sein. Aber ich hatte ne Runtime dabei das weiß ich noch. Ja, natürlich, die war immer dabei, auch später bei Visual Basic. Hintergrund war, dass das Runtime-Modul beim IBM PC im ROM lag und auf Clones anderweitig bereitgestellt werden musste.
:
Bearbeitet durch User
Percy N. schrieb: > Hintergrund war, dass das Runtime-Modjl beim IBM PC im ROM lag und auf > Clones anderweitig bereitgestellt werden musste. axo. Wusste ich nicht mal. Die Anleitung sagte, muss dabei, ergo muss dabei ;)
Schlaumaier schrieb: > Powerbasic lief OHNE. Und da war auch das ISAM-Modul für den > Datenbakzugriff drin. Welche Version war das? Bis PB 3.5 mindestens gab es kein ISAM, soweit ich mich erinnere.
Percy N. schrieb: > Welche Version war das? Bis PB 3.5 mindestens gab es kein ISAM, soweit > ich mich erinnere. Das war Power-Basic 3.0 . Bin ich ganz sicher. Ich habe nämlich mir gerade die Disketten angesehen. Und für das ISAM-Modul habe ich Extra Disketten. Alle im Jahre 1993 Herausgegeben. Eine heißt z.b. . PowerISAM **Betatest-Netzwerk** Version : 11.03.93 (c) by Thor. Meine Powertools (I + II) sind von 1990. Ich habe auch die anderen Module. Es gibt NIX was Kirschbaum rausgegeben hat, was ich nicht habe. Sogar ne Diskette die nicht von Kirschbaum ist. Ich habe den in den Powertools einige Fehler nachgewiesen. Deshalb haben die mich zum Beta-Tester "befördert" und ich bekam alle paar Wochen ne neue Diskette zugeschickt. Ich habe am Anfang der Entwicklung der Version 2.0 noch meine eigene Datenbank benutzt Also einige Index-Dateien und Relationaler Zugriff mit festen Feldgrößen. Nicht schön aber selten,und es hat gut funktioniert. ;) Aber dann die ISAM eingebaut. Sie war halt doch bequemer. ;) (Version 1.* war GWBasic, Version 3.* war VB-3.0, Version 4.* war VB-6.0) Danach wurde es zu Aufwendig. Chef hat Outsourcing gemacht und ich wurde Projektmanager. Nur noch Befehlen, nix mehr selbst schreiben an den Teil. Muss mal testen ob die Disketten noch funktionieren ;) Stehen direkt neben MS-Dos 6.0 ;)
Schlaumaier schrieb: > Ich fasse es nicht, das Zeug gibts sogar noch für Win-10 !?!?! Aktuell eher nicht ...
Schlaumaier schrieb: > Siehe Win-11 wo man bei "Rechte Maustaste, erst mal unten hin klicken > muss, um Umbenennen zu finden. Ich bin mir sicher, dass auch unter Win-11 noch die F2-Taste zum Umbenennen einer Datei oder eines Eintrages funktioniert. Das geht doch schon seit vielen Windows-Versionen. Wer klickt denn da noch umständlich mit der rechten Maustaste auf "Umbenennen"?
Schlaumaier schrieb: > Aber ich rege mich auch über deutsche Formeln in Excel auf, als von da > her...... Ich habe zum besseren Lernen der Sprache mein System auf Finnisch umgestellt. Excel zu benutzen ist damit schon eine ziemliche herausforderung :D
Noah schrieb: > Ich habe zum besseren Lernen der Sprache mein System auf Finnisch > umgestellt. Eine wirkliche Herausforderung wäre Mandarin! ;-)
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.