Anders Melander

No - for the reason Cristian stated.

First of all you can't just edit the compiled files in an editor. Forget about that. The BPL and DCP files are generated by the compiler when you compile the source code. Since you're trying to do edit the compiled files I'm assuming you don't have the source for this application or can't recompile it for some reason - or have no clue about what you're doing (that's okay too 🙂). If the queries are built in code, and you can't recompile, then you're pretty much out of luck as you would have to patch in the modifications at the assembler level. However if the queries are implemented in TQuery components, or something like it, and stored in DFM resources, then you can use a resource editor to extract the DFM of the form/datamodule where the query resides, change the SQL and then replace the DFM in the resource.

Delphi 1

Don't use the IDE managed version resource. Use an external RC file with a version resource instead and update it with whatever suits your build pipeline best. For example a simple bat or cmd file. I'm sure there are lots of homegrown utilities that can update the version in the dproj, an RC or RES file but I like to keep the number of dependencies down. A utility would just be yet another piece of software to install, maintain, etc.

Components has nothing to do with it. What I'm saying is that if you have your aeSuperDuperUtilities.pas unit, and you use that unit in different projects, then don't compile it in one project and use the DCU in another. It's okay to share the source file between projects (it would be better if you didn't, but that's another matter) but don't share the DCU files. Let each project have their own DCU output folder and don't use precompiled DCUs (the VCL/RTL being the exception). Even for something as huge as DevExpress (1700 DCU files, ~370 Mb) I never use the precompiled DCUs. I don't care about the minor improvement in compile speed sharing DCUs can give me. I do care about the time that is wasted when I have to track down some obscure problem caused by using out of sync DCUs.

I have no idea about what you are asking. Please rephrase the question.

I'm not sure what you are referring to there, but I was referring to the statements that: It's wrong to have the TMyButton class and the Register produce in the same unit. You need to have both a design- and a run-time package. This requirement is documented. Yes. I'm sure. In one of the many discussions I've had with Remy on this topic I checked the documentation all the way back to Delphi 1 and nowhere does it state that one must (or should) have both a design-time and a run-time package. I have also failed to find any other authoritative sources for the claim. It's always something that people heard from a friend of their 2nd cousins yoga teacher - or something like that 🙂 My claim is that, unless you link with run-time packages or share code between design-time packages, it's perfectly acceptable to put everything into a design-time package if you can. I.e. you don't need the run-time package. This also makes creating and maintaining design-time packages so much easier.

Bad idea IMO. Sharing DCUs among projects only leads to problems in my experience. When I do a clean build I want everything built from scratch, with the options I have enabled at that time. I don't want the compiler to link in some old DCUs that were compiled with god knows what options. You don't need to (as I explained) but it's cleaner design to separate design-time code from run-time code.

MadExcept has an option to compile with memory overrun/underrun checks enabled. It makes heap allocation really slow and add a lot of overhead but it's good if you suspect a memory overwrite and have no clue about where the problem originates. I don't know if Eurekalog has something similar.

Waitamoment! You can't make a 64-bit design-time package. The Delphi IDE is 32-bit so design-time packages needs to be 32-bit. Edit: Okay I need pay better attention. I can see you've already figured this out. If you already have all the components registered in the original (design- and run-time) package then why are you even bothering with creating a new package? Are you actually using run-time packages? It sounds more like your project is misconfigured if it needs precompiled dcus (e.g. from compiling a package) in order to compile.

Yes it's normal that it compiles. RegisterComponents is a regular function located in the classes unit and if you couldn't use classes.pas from a run-time package then you couldn't do much at all. You don't necessarily need to have both a run- and design-time package (yes, there are different opinions on that) but if you have decided to split the packages into run- and design-time then I guess you should move the RegisterComponents into separate registration units and place those in the design time package.

Since FQueueLock is instantiated in the TThreadedQueue constructor and destroyed in the destructor my guess would be that you are calling PushItem on a TThreadedQueue instance that has been destroyed - or not yet instantiatred. If you can reproduce in the debugger, try placing a breakpoint on the place where you create the TThreadedQueue and one on the place where you destroy it. This way you should be able to verify that things are called in the order you expect.

RAM disks... Didn't we stop using those along with DOS and Windows 95? Of course a dedicated physical RAM disk device will always be faster than an SSD but if you're allocating main system memory for use as a virtual RAM disk device then I think it would be better to let the OS manage the memory. It will use the memory to cache files when the memory isn't needed elsewhere.

Not even the part that's wrong?

And there's a lesson in that.

That doesn't answer the question. The overall category is "Delphi" and the Q doesn't have anything to do with Delphi. You have a better chance of getting a usable answer to stuff like this on stackoverflow.

What does this have to do with Delphi?

I thought you said that you didn't read books... 🙂

As Davis said it really depends on the level of security you need. Since the users will presumably have unlimited access to the client binaries the best you can hope for is security through obscurity. Once you accept that your choice depends on the value (to the user) of the assets you are trying to protect. You just need to make circumventing your protection sufficiently costly (in time) for the user that they won't bother. Since I don't know any of those metrics I can't really recommend a solution. Yes. Everyone can setup a domain controller and name is anything they want.

It's not secure at all. Nothing prevents someone from setting up a local PC, or even a VM, with the same config as one on your domain.

My build server runs all builds in parallel. I don't do it locally as I don't need to build more than one project at a time there.

So don't use shared dcu output folders. You shouldn't be doing that anyway.

Build them in parallel.

It's obvious that you, at some point in your pipeline, have the bitmaps in a TBitmap, but it's not obvious if this is actually necessary. If you don't have a requirement that the bitmaps need to be represented as a TBitmap then you can avoid the whole GDI overhead by simply loading the bitmaps as a memory stream and accessing the pixel data directly in memory. BMP is a fairly simple and well defined format so it's not that hard. You can also use something like Graphics32 to do this for you since this seems to be about 32-bit bitmaps exclusively.

Your TRGB32 type is identical to TRGBQuad. Why have you declared the TRGB32Array array packed? It serves no purpose. Why do you use TWICImage but also explicitly reference the Jpeg unit? One thing that I don't think you've mentioned, or at least I can't remember, is if you actually need to use TBitmap at all. Where does your bitmap data originate? A disk file, a stream, something else?