Important announcement: there is an English version of this forum on
Datum:
Ich suche einen kostenlosen Texteditor für Win32, der mit großen Dateien (>>1GB) umgehen kann. Die meisten Editoren die ich kenne stürzen bei sowas einfach ab. Kennt jemand ein solches Programm?
Datum:
OT: Was macht man mit soOoOo grossen Dateien? Da passen doch ganze Bibliotheken rein...
Datum:
Markus Kaufmann schrieb: > Ich suche einen kostenlosen Texteditor für Win32, der mit großen Dateien > (>>1GB) umgehen kann. Die meisten Editoren die ich kenne stürzen bei > sowas einfach ab. > > Kennt jemand ein solches Programm? schau mal hier http://www.winvi.de/en/
Datum:
Ich stand auch schon mal vor dieser Fragestellung, leider ist es schon ein paar Jahre her und ich kann micht nicht mehr genau erinnern, welcher Editor nun funktioniert hatte. Aber um noch ein paar auszuprobieren ;-) http://en.wikipedia.org/wiki/List_of_text_editors
Datum:
David ... schrieb: > OT: Was macht man mit soOoOo grossen Dateien? Da passen doch ganze > Bibliotheken rein... Das sind z.B. Messdaten. Teilweise würde da schon ein Textviewer reichen (aber sowas gibts heutzutage ja kaum noch), teilweise muss man noch eine Kleinigkeit ändern.
Datum:
Platinenschwenker .. schrieb: > schau mal hier > > http://www.winvi.de/en/ "large files upto 2 gigabyte editable" Das ist ja schonmal ein Anfang, obwohl ich eigentlich vi nicht mag. Danke für den Hinweis. Markus
Datum:
Markus Kaufmann schrieb: > Platinenschwenker .. schrieb: >> schau mal hier >> >> http://www.winvi.de/en/ > > "large files upto 2 gigabyte editable" > > Das ist ja schonmal ein Anfang, obwohl ich eigentlich vi nicht mag. > > Danke für den Hinweis. > Markus Ich benutze auch lieber z.B. diesen hier http://www.scintilla.org/ aber ob der so große Dateien abkann? Glaub' eher nicht.
Datum:
Markus Kaufmann schrieb: > David ... schrieb: >> OT: Was macht man mit soOoOo grossen Dateien? Da passen doch ganze >> Bibliotheken rein... > > Das sind z.B. Messdaten. Mag ja sein, aber wer verbietet dem Messprogramm, mehrere Dateien anzulegen anstatt einer riesengroßen? Und jetzt sag bitte nicht "Es wird bereits so gemacht..." :-)))
Autor:
Abdul K.
(ehydra)
Datum:
Hm. Kenne für Win auch keinen solchen Editor. Kippe es doch mal in eine Textverarbeitung. Die muß schließlich auch ein ganzes Buch in der Entwurfsfassung verwursteln können. Mit Bildern sollte da problemlos 100MB zusammenkommen. Mit reinem Text wird es allerdings schwierig. Wie war das? 2000 Zeichen pro Schreibmaschinenseite. Buch ist tausend Seiten dick. Macht 2MB. Für den Mac gibt es so einen Editor. Sollte es also für Win auch geben.
Datum:
Ultraedit kann das ohne Probleme, habe auch schon mit dateien > 4GB gearbeitet.
Datum:
Markus Kaufmann schrieb: > Ich suche einen kostenlosen Texteditor für Win32, der mit großen Dateien > (>>1GB) umgehen kann. Die meisten Editoren die ich kenne stürzen bei > sowas einfach ab. > > Kennt jemand ein solches Programm? Ich tippe auf Notepad++. Probier mal und berichte. http://notepad-plus.sourceforge.net/de/site.htm Hab keine so große Textdatei zur Hand aber ich erinnere mich, dass ich da bei einer sehr großen Datei weiter kam als mit Pspad.
Datum:
Mark Brandis schrieb: > Mag ja sein, aber wer verbietet dem Messprogramm, mehrere Dateien > anzulegen anstatt einer riesengroßen? Das könnte man machen, aber dann wird das Handling insgesamt wieder komplizierter. Das wollte ich vermeiden. Abdul K. schrieb: > Kippe es doch mal in eine > Textverarbeitung. Die muß schließlich auch ein ganzes Buch in der > Entwurfsfassung verwursteln können. Mit Bildern sollte da problemlos > 100MB zusammenkommen. 100MB kann jeder Popeleditor. Das ist bloß viel zuwenig. Außerdem sind meine Zeilen meist auch ziemlich lang (z.B. 2000 Zeichen), das ist mit einer Textverarbeitung typischerweise eher unpraktisch. Helmut S. schrieb: > Ich tippe auf Notepad++. Probier mal und berichte. Das hatte ich schon probiert. Und Programmers Notepad2. Beide sind abgestürzt. Markus
Datum:
Der Editor ist die eine Sache. Es bleibt aber die interessante Frage ob Dein Meßprogramm diese Datei zu DIESER Zeit noch benutzt. Dann kommt die Folgefrage ob der Editor evtl. aktuelle Meßwerte verhindert. Über 1GB eine neue Datei anzufangen dürfte auch von der Laufzeit und vom RAM her die günstigere Lösung sein?
Datum:
Probier es mal mit einem Hex-Editor. Die können mit großen Dateien teils sehr gut umgehen und zeigen den Inhalt der Datei nicht nur in Hexdarstellung, sondern auch als ASCII-Text dar. Manipulation der Datei ist natürlich auch möglich. Habe mal schnell für Win* nach einen gesucht und bin auf "avihex" gestoßen. Bei den "Features" steht an erster Stelle: "no Limit of File Size" Quelle: http://www.gero-net.de/avihex/index.htm
Datum:
UltraEdit kann sehr große Files öffnen. Es dauert aber recht lange, bis er sie öffnet, was vermutlich daran liegt, dass er sich eine Kopie anlegt. Und beim durchscrollen dauert es wieder. Das sieht dann im ersten Moment wie ein Absturz aus. Das ist zumindest die Erfahrung, die ich mit einer recht alten Version gemacht habe. Vielleicht hättest du bei den Tests mit den anderen Editoren länger warten sollen?
Datum:
> UltraEdit kann sehr große Files öffnen. Es dauert aber recht lange, bis > er sie öffnet, was vermutlich daran liegt, dass er sich eine Kopie > anlegt. Und beim durchscrollen dauert es wieder. Das sieht dann im > ersten Moment wie ein Absturz aus. Das ist zumindest die Erfahrung, die > ich mit einer recht alten Version gemacht habe. ja so ist es, und weil die entwickler das wissen haben sie eine möglichkeit geschaffen es abzuschalten - bei den option für dateihandling. Noch schnell geht es wenn man noch die Zeilennummer ausschaltet.
Datum:
Nachdem ich zu spät den Beitrag von 'Mano Wee' gesehen habe: Sehr schnell und imho unabhängig von der Filegröße öffnet WinHex http://www.x-ways.net/winhex/index-d.html jeden File. Aber dies ist ein Hexeditor und interpretiert in der ASCII-Anzeige leider keine Zeilenumbrüche (in meiner noch alten Version). Die Grundfunktion gibt's für private Nutzung frei. Peter schrieb: >ja so ist es, und weil die entwickler das wissen haben sie eine >möglichkeit geschaffen es abzuschalten - bei den option für >dateihandling. Richtig, hatte ich vergessen. Er legt dann kein Backup an. Beide lassen übrigens die Möglichkeit zu, dass ein anderes Programm den File zwischenzeitlich ändert - UEDIT aber nur, wenn die von Peter beschriebene Option nicht aktiv ist.
Autor:
Patrick Dohmen
(oldbug)
(Moderator)
Datum:
Aus dem Bauch raus würde ich sagen, dass emacs das kann. Der bringt auch noch ganz andere Vorteile mit sich :-D
Datum:
Markus Kaufmann schrieb: > Ich suche einen kostenlosen Texteditor für Win32, der mit großen Dateien > (>>1GB) umgehen kann. Die meisten Editoren die ich kenne stürzen bei > sowas einfach ab. > > Kennt jemand ein solches Programm? Nimm' gvim (http://www.vim.org/). Zumindest unter Unix/Linux ist er nur an die maximele Dateigröße des Dateisystem gebunden. Ist kompatibel zum "Ur-vi", hat aber auch einen Kompatibilitätsmodus, so dass er ganz "gewöhnlich" zu bedienen ist. Ist ein ziemlich mächtiger Editor, den ich nicht mehr missen möchte. Gruß, Bernd
Autor:
Andreas Schwarz
(andreas)
(Admin)
Datum:
Weder vim noch emacs sind dafür geeignet, beide laden die komplette Datei ins RAM.
Autor:
Abdul K.
(ehydra)
Datum:
Markus Kaufmann schrieb: > 100MB kann jeder Popeleditor. Das ist bloß viel zuwenig. > Außerdem sind meine Zeilen meist auch ziemlich lang (z.B. 2000 Zeichen), > das ist mit einer Textverarbeitung typischerweise eher unpraktisch. > Nein! Die Frage ist, ob der Editor Dateien größer als die mögliche RAM-Zuteilung für sich selbst öffnen kann, also in Stückchen arbeitet und dieses richtig zusammensetzt/verwaltet. Wenn dein PC also eh 1GB RAM hat, ist das kein Test!
Datum:
>RAM-Zuteilung
Dann schau doch mal mit systeminfo
Total Physical Memory: ???? MB
Available Physical Memory: ???? MB
Virtual Memory: Max Size: 2.048 MB
Virtual Memory: Available: 2.007 MB
Virtual Memory: In Use: 41 MB <=========
Page File Location(s): x:\pagefile.sys
usw.
... ob da überhaupt der Platz reicht für Deine Experimente.
Autor:
Abdul K.
(ehydra)
Datum:
Meinst du mich? Ich öffne solche Riesendateien normalerweise nie. Kommen für mich nur als Film oder pdf vor. Und da habe ich ja die Spezialeditoren in Form von pdf-Reader bzw. VLC. Wo soll 'systeminfo' eigentlich sein?
Datum:
Markus Kaufmann schrieb: >> Ich tippe auf Notepad++. Probier mal und berichte. > Das hatte ich schon probiert. Und Programmers Notepad2. Beide sind > abgestürzt. Die Frage ist, sind die Editor wirklich abgestürzt oder brauchen sie noch mehr Zeit. Ich habe mal eine exe-Datei, die Bilder als Dia-Schau angezeigt hat, mit dem Windows-eigenen Notepad-Ersatz geöffnet. Lass mich lügen, Wordpad-MFC oder so heißt der imho. Das ist knapp 8 Jahre her und war mit dem Notepad sehr schnell, da der sofort abstürzte mit dem Wordpad dauerte es 40 Minuten, ging aber. Ansonsten solltest du mal verraten, welche du ausprobiert hast und nicht gehen.
Datum:
Abdul K. schrieb: > Wo soll 'systeminfo' eigentlich sein? In der cmd.exe, ist imho aber nicht bei allen Windowsversionen vorhanden. http://technet.microsoft.com/en-us/library/bb491007.aspx
Datum:
Das Wichtige an so einem Editor ist die Scroll- und Suchfunktion. Ohne kann's muehsam werden.
Autor:
Abdul K.
(ehydra)
Datum:
eklige Tunke schrieb: > Abdul K. schrieb: >> Wo soll 'systeminfo' eigentlich sein? > In der cmd.exe, ist imho aber nicht bei allen Windowsversionen > vorhanden. > > http://technet.microsoft.com/en-us/library/bb491007.aspx Systeminformationen unter Zubehör zeigt auch solche Werte an.
Datum:
mit gVim konnte ich gerade eine 2.8GB Datei unter XP öffnen. Hat etwas gedauert aber abgestürtzt ist nichts.
Datum:
eklige Tunke schrieb: > Markus Kaufmann schrieb: >>> Ich tippe auf Notepad++. Probier mal und berichte. >> Das hatte ich schon probiert. Und Programmers Notepad2. Beide sind >> abgestürzt. > Die Frage ist, sind die Editor wirklich abgestürzt oder brauchen sie > noch mehr Zeit. Wenn ich mich recht erinnere, dann sind beide abgestürzt. Ich könnte mich beim Notepad++ aber auch täuschen: Ich habe es gerade nochmal getestet und da zeigt sich, dass er ewig braucht, aber dabei kaum Rechenzeit benötigt. Das ist normalerweise schon ein deutlicher Hinweis auf einen Absturz. Öffnen kann er sie allerdings nicht, irgendwann sagt er dann, dass ihm die Datei zu groß sei. > Ansonsten solltest du mal verraten, welche du ausprobiert hast und nicht > gehen. Außer dem Windows-Editoren im wesentlichen nur den erwähnten Notepad++ und PN2. Aber wozu willst Du das wissen? Suchst Du dann für mich im Netz nach besseren Editoren? Ich hatte mir das einfach so gedacht, dass die Leute mir die Editoren nennen, von denen sie wissen, dass sie das können. Ganz ohne Aufwand. Ultraedit wurde schon genannt, der ist aber kommerziell. J-Write könnte das wohl auch, aber der ist ebenfalls nicht umsonst. Markus
Datum:
Sorry für die Thread-Nekromantie, der 010-editor ist auch hervorragend, und für die ersten 30 Tage kostenlos.... thegun ist ... seltsam, funktioniert aber auch schön.
Datum:
Der Thread hier ist schon ziemlich alt. Keine Ahnung ob´s noch jemandem nutzt, aber für solche Fälle ist unter Windows baretail von BareMetal Software sehr zu empfehlen. Das Programm ist kostenlos nutzbar. Baretail ist eigentlich ein Echtzeit-Logfile-Viewer (und blockiert damit auch andere schreibende Prozesse nicht). Es läd immer nur den sichtbaren Bereich der Datei. Der Speicherverbrauch bleibt dadurch auch bei sehr großen Dateien im Rahmen (< 20MB). Baretail hat zwar keine Suchfunktion, aber einen konfigurierbaren Highligter (Schrift- + Hintergrundfarbe je gesuchter Zeichenkette).
Datum:
Meine ganz klare Empfehlung: PilotEdit. Vor allem auf schwächeren Systemen. Moby
Datum:
richtiges Betriebssystem verwenden. Das geht bei Linux mit fast jedem Editor. Was nicht in den Speicher (RAM) passt, wird eben auf Platte ausgelagert.
Datum:
Markus Kaufmann schrieb: > Ich suche einen kostenlosen Texteditor für Win32, der mit großen Dateien > (>>1GB) umgehen kann. Die meisten Editoren die ich kenne stürzen bei > sowas einfach ab. Nun, wen wunderts? Nein, wirklich, Programmierer werden sofort sehen warum, auch wenn es für den Berufsstand mehr als peinlich ist... Für so grosse Datenmengen wird ein 64-Bit-System schwer empfohlen... > Kennt jemand ein solches Programm? Hmm, guckst Du hier: http://en.wikipedia.org/wiki/Comparison_of_text_editors .
Datum:
context solls ja auch können und kost nix. ausserdem gibts ja immer noch sed.
Datum:
Man kann so ein Dateimonster au in handliche Brocken zerlegen und dann mit jedem beliebigen Editor bearbeiten.
Datum:
Jasch schrieb: > auch wenn es für den Berufsstand mehr als peinlich ist... Der Umgang mit Textdateien beliebiger Grösse war schon beim Editor HS von Borland für MSDOS gelöst, meine Version ist vom 19.3.1992. Dazu gabs sogar den Source-Text. Irgendwann seither hat sich aber die Auffassung durchgesetzt, speichersparendes Programmieren sei total uncool. Selbst wenn man nur ein paar Bytes im Header einer Bilddatei prüfen will, lauten alle heutigen Empfehlungen und Musterprogramme: erstmal die Datei in den Speicher laden, dann sieht man weiter... Gruss Reinhard
Datum:
Reinhard Kern schrieb: > Selbst wenn man nur > ein paar Bytes im Header einer Bilddatei prüfen will, lauten alle > heutigen Empfehlungen und Musterprogramme: erstmal die Datei in den > Speicher laden, dann sieht man weiter... Das ist ja i.d.R. virtueller Speicher, der bei Bedarf ausgelagert werden kann, ohne daß der Programmierer dafür auch nur einen Finger krumm machen muß. Davon konnte man zu DOS-Zeiten nur träumen...
Datum:
Mal davon abgesehen, dass ich die Anfrage vor 2,5 Jahren gestellt habe: Man kann es sich halt nicht immer aussuchen, ob man ein Betriebsystem mit 32 oder 64 Bit verwendet. @Reinhard Kern: Ja, darüber reg ich mich auch auf. Insbesondere bei Hexeditoren, denn bei denen müsste man einfach nur aufs Einfügen/Löschen verzichten und schon wirds ganz einfach zu programmieren.
Datum:
Reinhard Kern schrieb: > Selbst wenn man nur > ein paar Bytes im Header einer Bilddatei prüfen will, lauten alle > heutigen Empfehlungen und Musterprogramme: erstmal die Datei in den > Speicher laden, dann sieht man weiter... Das ist bei anständigen Betriebssystemen ja auch sinnvoll. Denn es handelt sich, wie Uhu richtig schrieb, um virtuellen Speicher, den das Betriebssystem nach Bedarf auf die Festplatte auslagern kann. Der Programmierer des Editors muss sich darum nicht kümmern. Bei Microsoft dauert es halt immer ein paar Jahrzehnte länger, bis sie übliche Techniken in ihre Produkte einbauen. > Man kann es sich halt nicht immer aussuchen, ob man ein Betriebsystem > mit 32 oder 64 Bit verwendet. Dazu braucht man keine 64 Bit. Das ging vor 20 Jahren auf meinen 486er auch schon.
Datum:
Markus Kaufmann schrieb: > Ja, darüber reg ich mich auch auf. Insbesondere bei Hexeditoren, denn > bei denen müsste man einfach nur aufs Einfügen/Löschen verzichten und > schon wirds ganz einfach zu programmieren. Warum sollte ich mir als Entwickler viel Arbeit machen fuer eine Nischenanwendung, noch dazu wenn ich anschliessend mit solchen Kommentaren rechnen muss: > Ultraedit wurde schon genannt, der ist aber kommerziell. Ich warte gespannt auf deinen Gratiseditor, der die von dir genannten Anforderungen erfuellt.
Datum:
Marwin schrieb: > Ich warte gespannt auf deinen Gratiseditor, der die von dir genannten > Anforderungen erfuellt. Bitteschön: http://www.vim.org/
Autor:
Rufus Τ. Firefly
(rufus)
(Moderator)
Datum:
b.c. schrieb: > Bei Microsoft > dauert es halt immer ein paar Jahrzehnte länger, bis sie übliche > Techniken in ihre Produkte einbauen. Bereits Windows NT 3.1 (1993!) kannte "memory mapped files", mit denen genau das beschriebene Verhalten möglich war, und das sogar recht effizient. Warum keiner der üblichen Frickelprogrammierer es jemals für nötig gehalten hat, sich die Win32-API-Dokumentation auch mal anzusehen, das entzieht sich sowohl meiner Kenntnis als auch meinem Verständnis.
Datum:
b.c. schrieb: > Das ist bei anständigen Betriebssystemen ja auch sinnvoll. Denn es > handelt sich, wie Uhu richtig schrieb, um virtuellen Speicher, den das > Betriebssystem nach Bedarf auf die Festplatte auslagern kann. Der > Programmierer des Editors muss sich darum nicht kümmern. Ja - nee. Macht schon Sinn, einen Haufen Daten erstmal kopflos zu duplizieren, um dann in der Kopie ein paar Bytes zu Suchen, statt gleich im Original zu suchen, dass nicht mal mehr auf die Festplatte ausgelagert werden muss, weil es da schon liegt. Manche Programmiererlogik muss man erstmal verstehen und kann sich nur wundern.
Datum:
b.c. schrieb: > Reinhard Kern schrieb: >> Selbst wenn man nur >> ein paar Bytes im Header einer Bilddatei prüfen will, lauten alle >> heutigen Empfehlungen und Musterprogramme: erstmal die Datei in den >> Speicher laden, dann sieht man weiter... > > Das ist bei anständigen Betriebssystemen ja auch sinnvoll. Denn es > handelt sich, wie Uhu richtig schrieb, um virtuellen Speicher, den das > Betriebssystem nach Bedarf auf die Festplatte auslagern kann. Unnötige Daten in den Speicher laden kostet aber Zeit, und sie dann wieder zurück auf die Platte auszulagern kostet noch mal Zeit, und das nur, um sie dann zweimal auf der Platte stehen zu haben. Und dann werden geschickterweise noch Daten von anderen Prozessen nebenbei ausgelagert, so daß das dann nachher auch erstmal alles ganz langsam läuft, bis die Daten wieder ihren Weg in den Speicher gefunden haben. >> Man kann es sich halt nicht immer aussuchen, ob man ein Betriebsystem >> mit 32 oder 64 Bit verwendet. > > Dazu braucht man keine 64 Bit. Das ging vor 20 Jahren auf meinen 486er > auch schon. Höchstens bei Betriebssystemen, die mehrere 32-Bit-Datensegmente pro Prozess verwalten können. Mir ist keins bekannt, das das je getan hätte, und bei allen anderen ist der Adressraum pro Prozess eben inklusive reservierter Bereiche auf 4 GB beschränkt. Das konnte auch der 486er nicht umgehen.
Datum:
Gratisprogger schrieb: > Marwin schrieb: >> Ich warte gespannt auf deinen Gratiseditor, der die von dir genannten >> Anforderungen erfuellt. > Bitteschön: > > http://www.vim.org/ Mir waere neu, dass vim von Markus Kaufmann entwickelt wurde.
Datum:
Marwin schrieb: >> Ultraedit wurde schon genannt, der ist aber kommerziell. > > Ich warte gespannt auf deinen Gratiseditor, der die von dir genannten > Anforderungen erfuellt. Es geht dabei nicht darum, ob es Geld kostet oder nicht, sondern um den Aufwand der Anschaffung. Ich hab das vor allem bei der Arbeit gebraucht (mittlerweile nicht mehr) und da ist es deutlich leichter eine Matlab-Lizenz zu bekommen (weil das schon eingesetzt wird) als 50€ für einen neuen Texteditor. Privat ist das nicht so schwierig und da habe ich mich gegen Openoffice und gegen Gimp entschieden und Microsoft Office und Photoshop gekauft. Davon abgesehen kann ich nicht nachvollziehen, warum ich mir nur wünschen darf, was ich auch selber gebe.
Datum:
> ist der Adressraum pro Prozess eben inklusive > reservierter Bereiche auf 4 GB beschränkt. Es war hier aber von 1 GB die Rede.
Datum:
0815 schrieb: >> ist der Adressraum pro Prozess eben inklusive >> reservierter Bereiche auf 4 GB beschränkt. > > Es war hier aber von 1 GB die Rede. Der Prozess-Adressraum ist typischerweise aber nur 2 oder 3 GB groß und da viele Editoren ASCII-Dateien intern als Unicode darstellen braucht man für eine 1GB ASCII-Datei eben 2GB Speicher. Ich habe ja auch nach >>1GB gefragt, nicht exakt 1GB.
Autor:
Rufus Τ. Firefly
(rufus)
(Moderator)
Datum:
Markus Kaufmann schrieb: > Der Prozess-Adressraum ist typischerweise aber nur 2 oder 3 GB groß Nichts hindert einen Editor daran, nur einen Teil der Datei im Arbeitsspeicher zu halten - mit o.g. "memory mapped files" ist das unter Windows seit Urzeiten möglich, da die zugehörigen Funktionen schon mit 64-Bit-Dateizeigern gearbeitet haben, als Festplatten noch sehr problemlos mit 32 Bit komplett adressiert werden konnten.
Datum:
Memory-Mapping für einen Editor halte ich für - ähem - "suboptimal". Der Dateiinhalt ist im Fehlerfall (Editor stürzt ab, Stromausfall) schnell mal in einem fragwürdig-konsistenten Zustand. Hat einen guten Grund, dass Editoren mit Sicherungskopien oder ähnlichem arbeiten. Für einen nur lesenden Viewer ist - bzw. wäre - Memory-Mapping natürlich die optimale Lösung.
Datum:
Zudem lässt Memory-Mapping nur sehr eingeschränkte Editoroperationen zu, nämlich Lesen und Überschreiben. Einfügen und Löschen sind damit nicht vernünftig realisierbar. Für einen Hex-Editor, mit dem ein paar Bytes in einer größeren Datei geändert werden sollen, ist Memory-Mapping prinzipiell in Ordnung, aber eben auch nur, solange die Dateigröße die Größe des virtuellen Adress- raums nicht überschreitet. Soll bspw. eine ganze Partition oder gar eine Festplatte editiert werden, ist diese Bedingung auf 32-Bit-Systemen praktisch immer verletzt. Es ist aber auch kein großer Programmieraufwand, statt über Memory- Mapping per seek() einzelne Dateipositionen anzufahren und dort die entsprechenden Bytes zu modifizieren.
Datum:
Yalu X. schrieb: > auch nur, solange die Dateigröße die Größe des virtuellen Adress- > raums nicht überschreitet. Die Datei muss nicht vollständig gemappt werden. Das läuft dann eben wie bei seek(), nur ohne die Daten einzulesen.
Datum:
0815 schrieb: >> ist der Adressraum pro Prozess eben inklusive >> reservierter Bereiche auf 4 GB beschränkt. > > Es war hier aber von 1 GB die Rede. Markus Kaufmann schrieb: > Ich suche einen kostenlosen Texteditor für Win32, der mit großen Dateien > (>>1GB) umgehen kann. ">>1GB" heißt für mich soviel wie "Sehr viel größer als 1 GB".
Datum:
Ich benutze PilotEdit Lite Freeware für grosse Text Dateien. Soll bis zu 10 GB können. http://www.pilotedit.com/ PilotEdit kann noch mehr, kostet aber was.
Datum:
EmEditor
Datum:
010 Editor
Datum:
Abdul K. schrieb: > Sind beide nicht kostenlos! Ach ja, hast recht. Die Leute wollen ja immer beste Ware, aber kostenlos... Hatte ich vergessen.
E-Mail-Benachrichtigung einschalten
Neu: Seitenaufteilung einschalten