Anders Melander

map2pdb has code to read and update the PE header and add a section. You might be able to tweak that into whatever it is you're doing. https://bitbucket.org/anders_melander/map2pdb/src/master/Source/debug.info.pdb.bind.pas

You are talking about self-modifying code or simply the ability of a process to alter its own page-level protection. While that is an OS feature that is used to implement embedded DLLs it isn't specific to it. Lots of other application techniques use that feature. I thought you meant that embedded DLLs posed a risk to the applications using them. It seems you mean that an application using embedded DLLs potentially poses a risk to the system as a whole. By extension of that argument, you could just as well argue that compiled code is unsafe and that all applications must be distributed as source and compiled by the user. But since you are not going to argue, let's not go there 🙂

I fail to see how. Can you give an example? Using an embedded DLL, the application executes code that it itself has supplied and linked. If anything, this should be safer than loading an external DLL from disk and executing code in that. This is not "getting into the system". Everything happens in user mode within the application.

I can't see how they could prevent it without breaking a lot of applications that are doing similar (but not necessarily the same) things. It's basically just juggling page protection and modifying memory. All done in USER-level. Also, why should it pose a security threat?

Because the manifest controls the runtime environment where Windows execute your application. If your application doesn't have a manifest (internal or external), then Windows assumes that your application is completely clueless about the environment and gives you one where you can party like it's 1999. Apart from that, you seldom need to use a custom manifest; The one generated by Delphi should be good enough for most uses. Try examining the manifest setting in your project again.

It's included in the .res file generated by Delphi so you can examine it with a resource editor.

No, He means this:

That's one interpretation but just because the Wikipedia page states it (unsourced, incidentally) doesn't make it so. Another is that it's the most pirated version (the last version without license activation). Yet another is the self-goal of Delphi 8. It's impossible to know. Funnily, if you follow the edits on the wiki, the section you quoted at one point stated:

Ah, yes. Forgot about that one. It's too bad your changes from Martin Offenwanger's version predate the Git repo. That makes it pretty impossible to identify the changes. It does look like they have been updated independently since the fork though. FWIW, I can see you have a fix similar to mine in your version. I do think it's fairly well-documented but I will agree that it's pretty complex and not for the faint of heart (The implementation of it, that is. The use is trivial). I think my attitude toward it would be: If it works right away use it, otherwise don't bother with it. As I wrote, I've been using it for years without any problems.

I've been loading DLLs from resources for years using Martin Offenwanger's BTMemoryModule: https://github.com/DSPlayer/memorymodule It's a Pascal port of Joachim Bauch's solution: https://www.joachim-bauch.de/tutorials/loading-a-dll-from-memory/ I have a small patch that I have never gotten around to committing to the BTMemoryModule repo. If you elect to go the BTMemoryModule route let me know and I will push a pull request to the repo.

Yes, you did. My bad. Time for bed 🙂

Have you benchmarked this against some of the existing Gaussian blur implementations? It's a bit difficult to decode the algorithm you use due to the lack of comments in the source but it appears you are just applying a Gaussian kernel (with some additional logic) and that approach is usually quite slow. I have a benchmark suite that compares the performance and fidelity of 8 different implementations. I'll try to find time to integrate your implementation into it. With regard to the ratio between Radius and Sigma, it's my understanding that: Ratio = 1 / FWHM (Full Width at Half Maximum) = 1 / (2 * Sqrt(2 * Ln(2))) = 0.424660891294479 But you have a ratio of 0.5 Have I misunderstood something?

It looks to be one of the most underwhelming releases I've seen in a while.

It is a portable computer that goes with me everywhere. So it restarts for almost every few days. it is a Lenovo server very powerful. One of these things is not like the other. One of these things doesn't belong...

Oh, you think? Yes, of course you can do that. You don't need a special library to decode a jpeg in a thread.

Yes, but not that different. There's a difference of 14,307,328 bytes between his two files and one of them has an extra PE section... Anyway, if he can't be bothered to compare the files in a proper tool and tell us what that extra section contains, then I think I'll spend my time on something else; The lawn needs mowing.

I have no idea about what you are trying to say here. I don't speak Haiku...

https://petoolse.github.io/petools/

If you can, try to determine the type and content of the extra PE section.

Do you use madExcept, Eurekalog, or something like that? It could be that something modifies the exe post-link. It could also just be something not so nice adding its own payload to your application...

Yes, there will of course always be some parts that can be parallelized but the problem is that the expensive part, the Huffman decoding, cannot. I'm guessing they used "cooked" jpegs because there's really not much magic that can be done here. I think the effort is better spent on using SSE, AVX, or the GPU to decode - which is also what I believe most high-performance decoders do.

Most modern jpegs require sequential decompression due to the compression algorithms used (decompression of a block is based on the result of the previous block); There's nothing much to parallelize. Jpegs with lots of restart markers (a restart marker means that the result of the previous blocks isn't needed) in the compression stream would benefit from parallelization but it is my understanding that those have become very rare as the problem they were meant to solve (data corruption during download via modem) no longer exist.

Yes, unfortunately.

I think the IDE form designer might work around that; Only one design form can be visible at a time. Just a guess.

The address space of a 32-bit application is 4GB. Some of that is reserved by Windows. By default 2GB but for Large Address Aware applications (such as the Delphi IDE) it's 1 GB. These values can be customized globally. Your hardware configuration (motherboard, etc..) can have an effect on the reserved size, btw. https://learn.microsoft.com/en-us/windows/win32/memory/virtual-address-space If you are running out of memory at 2.5GB then the IDE is trying to make an allocation of 0.5 GB or more. This seems unlikely so there could be something else going on. You might wait to check the size of "hardware reserved memory" on your system. 100 forms open at the same time is hardly a typical use case. Why would you ever want that? FWIW, I just tried opening all the over 600 forms, frames and datamodules of a project with around 3 million lines of code. It uses DevExpress ribbon, docking, skins, grids, and controls, FireDAC, etc. That consumed 3.4 GB but happily compiled and linked. It's a 64-bit project. I'm not saying that your problem isn't real but I don't think this problem is common enough that it alone justifies migrating the IDE to 64-bit. And I certainly don't think your rhetoric will help your case.