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......
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 ;)
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:
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?
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.
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.
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.
(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.
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)
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.
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:> 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
