Anders Melander

By "FastGaussian" I guess you mean the FastBlur routine? FastBlur is actually a box blur and not a true Gaussian blur. This is just fine for some setups, but not so great for others. Also, performance is, as you've discovered, not the only important metric when comparing blurs. Fidelity can also be important. It completely depends on what the blur is used for. Some algorithms are fast but suffer from signal loss or produce artifacts. Some are precise but slow. And then there are some that do it all well 🙂 The parameters below are [Width, Height, Radius]: Case in point, BoxBlur32 above is consistently the fastest but also has the worst quality and doesn't handle Alpha at all. Use floats and implement it with SSE. That's what I did 🙂

It's free for non-commercial use. And yes, it does handle exceptions in the initialization section.

Have you tried madExcept?

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.