Anders Melander

No. You want your media isolated from anything that can damage it. That includes the backup device. Build a lego robot if you want it automated A small fireproof safe isn't that expensive. 400 EUD will get you started and I'm sure they can be had for a fraction of that second hand.

Stackoverflow.

I have multiple projects that are heavily dependent on DWScript and I like to think I'm a bit of a DWScript expert after having used it for so many years (since 2002). However... It's a bit hard for me to judge if the implementation is "very clean" because the source is close to unreadable to me. The architecture might be solid but I have spent hours trying to solve problems by reading the source and the non-standard code style and the lack of comments in the code means it's futile to try to learn from the source. It has improved since DWS2 but not enough. Another problem is that there's zero documentation and the examples only covers very basic use cases. So expect a steep learning curve. Finally there's no community and it's maintained by a single person who doesn't seem interested in letting anyone else work on it. But apart from all that I can also recommend DWScript. Here's an IDE for DWScript if you need it: https://bitbucket.org/anders_melander/dwscriptstudio

And if everything else fails there's always the NSA to fall back on. https://www.cnet.com/news/guess-what-happened-when-backblaze-tried-using-the-nsa-for-data-backup/ https://o.canada.com/technology/internet/irony-alert-google-labels-nsa-data-centre-backup-service

Sure. If you want reliable backup use a media that has been designed for it. Floppies, writable CDs and DVDs, cheap HDDs, SDDs and SDs aren't reliable. I have TK-50 DLT tapes from the late eighties that can still be read (each tape contains a whopping 94Mb). The tape format is standard and the drive is SCSI so it's no problem finding a way to read them - and the data is still there. Try that with any other storage type after thirty years (stone tablets and punch cards excepted). I think it pretty irresponsible to make a statement like that. You can't guarantee anything like that and I'm pretty sure you will not take financial responsibility when your guarantee turns out to be false. The companies that make these devices doesn't even make such claims. It is known that SDD and SD degrade over time. Their good MTBF is only valid when they are new.

Design-time packages are always 32-bit only since the Delphi IDE is 32-bit. You don't need the package installed to build. You need them installed to have design-time support. E.g. being able to drop SynEdit controls and components on forms, set their properties at design time etc.

Oh, and another reason why this is wrong is that it's better for HDDs to run continuously. It's the power cycles that kills them (thermal wear).

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...