Anders Melander

If you care about speed use a SAX parser instead. The DOM model has different priorities.

It's a misconception that RAID is a means to better data security. RAID is a means to better performance or higher availability. If you buy cheap drives or cheap NAS with cheap drives in them then you get what you pay for. No surprise there really. The HDDs in my system are 16 years old and some of them have been running almost continuously. They're Western Digital WD5000YS drives with a MTBF of 137 years. I have two drives mounted internally and five drives in a hot-swap rack on the front for use as backup storage. Of course I also have a couple of SDDs for the performance critical stuff. HDDs have better reliability than SDDs and they are better for long term archival. While a brand new SDD might have better MTBF values than a HDD this dramatically changes with time as the drive is used. After only a few years the SDD will have deteriorated by a magnitude to have much worse MTBF than the HDD. So you're good with relying on the cheapest available devices to save you when your primary storage fails? Interesting. Personally I would prefer a reliable backup medium so that I could afford to use faster, but less reliable, primary storage devices.

Good choice. Keep it simple.

It's trivial to implement and then you get it just like you want it.

Instead of reinventing the wheel why not try one of the many existing solutions. For example Graphics32 or Image32. Here's a shot of an old demo of the GR32_Objects unit: and here's one of a similar Image32 demo:

...or the shorter version (yes, I know you said it): zip.Read(0, Result);

One thing you can do to make it a bit faster is to read directly from the decompression stream (SourceStream in my example) instead of copying it to a memory stream. AFAIR the decompression stream buffers internally and is bidirectional so you should be able to treat it as a memory stream.

That only resolves inter-package dependencies. Not application dependencies.

Tsk, tsk.

Something like this: var ZipFile: TZipFile; SourceStream: TStream TargetStream: TStream; LocalHeader: TZipHeader begin ... TargetStream := TMemoryStream.Create; try ZipFile.Read('foobar.dat', SourceStream, LocalHeader); try TargetStream.CopyFrom(SourceStream, 0); finally SourceStream.Free; end; ...do something with TargetStream... finally TargetStream.Free; end; end; There used to be a problem with unicode in comments but I believe that has been fixed.

Yeah, that one is really annoying. I used to have a class helper that added TZipFile.Delete and Remove methods but one of the Delphi versions after XE2 broke that one as the required TZipFile internal data structures are no longer accessible to class helpers.

Who knows what?

Have you read the help? Extract to stream: http://docwiki.embarcadero.com/Libraries/Rio/en/System.Zip.TZipFile.Read Extract to file: http://docwiki.embarcadero.com/Libraries/Rio/en/System.Zip.TZipFile.Extract

I can't see how that is relevant. Just because new control versions are added doesn't mean the old ones stop working. TRichEdit is a wrapper around the RICHEDIT20W window class (i.e. RICHED20.DLL). Override CreateParams to use another version if that's important.

If you need an example of what TRichEdit can do just run Wordpad. If you need examples of how to do it read the help or Google it. There are hundreds of examples. If you have an older version of Delphi installed there's even a richedit example project. I don't see the problem.

I would think that the compiler would do that for you - i.e. give you a compile or linker error. I must admit that my experience with run-time packages are a couple of decades old but AFAIR the dcu files of the packages are stored in a dcp file. If the linker uses the dcp file instead of the dcu files then a interface change should result in a linker error - but I might of course be remembering this completely wrong. Since run-time packages are just statically linked DLLs I believe you just need to determine if all DLL dependencies can be resolved. It would be trivial to create a small utility that loaded you application with LoadLibraryEx and have that do it, but unfortunately LoadLibraryEx only resolves dependencies when you load DLLs. Try Dependency Walker instead. It has a command line mode that you can probably use. I don't know what the output looks like though. Get rid of them (the packages, not the apps).

Move isn't the problem in this particular case. The problem is that once you logically remove an entry from the array then you need to finalize that entry in the array to clear the reference. You can do that by assigning Default(T) to the entry.

Because otherwise the buffer will still hold a reference to the T instance. For any managed type this will be a problem. For example what happens if T is an interface? Maybe some unit testing is in order...

...and how did these people get their experience?

Can someone explain why this fails to compile with E2029 Expression expected but 'ARRAY' found: begin var Stuff: array of integer; end; while this works: type TStuff = array of integer; begin var Stuff: TStuff; var MoreStuff: TArray<integer>; end;

Never mind. Known problem: RSP-21729: Inline var case complier error RSP-22359: Nameless types are not allowed within inline variable declarations

Yes I believe there are slight differences in the syntax but I simply can't remember them anymore. BRCC32 used to be a superset of RC back when Borland was a leader in development tools... So quite some time ago. If I could find some documentation of BRCC32 I could probably tell you what they are. See also:

Ah yes. I didn't spot that one. Easy to fix I guess. I don't understand the problem. Please educate me.

I can't see why using Move would be a problem as long as it just moves entries within the buffer array (which it does as far as I can tell). However there does seem to be a problem with not clearing empty slots in the array. E.g. by assigning Default(T) to them.

Well that a bug then. Report it and get it fixed. Since we're (you're) talking about external documentation the first part doesn't really matter but it's true that the link to the external help is broken when the signature changes. That rarely happens though.