Anders Melander

Well that turned out to be a big waste of time I can now produce a YAML file from the MAP file using my own tool and a PDB file from the YAML file with the LLVM tool. Unfortunately VTune couldn't care less. It turns out that in order for VTune to load the PDB file the file needs to be referenced in the PE debug section of the exe file. This is something Microsoft's linker does when you specify the /DEBUG option but Delphi's linker of course doesn't. I can't even patch the debug section Delphi's linker does produce since it's only a single byte. I assume that it's possible to patch the file by replacing the whole debug section and update the PE header but right now I don't know the required format of it. The format of the debug section is documented here: http://www.debuginfo.com/articles/debuginfomatch.html and http://www.godevtool.com/Other/pdb.htm I don't have time to pursue this any further right now, so I hope someone else is willing to have a go at it. I'll post my source when I have a spare moment.

Burned? DevExpress wouldn't have existed if it wasn't for Delphi.

I'm once again in need of a good 64-bit profiler so I've been looking into what would be needed in order to generate PDB files from whatever Delphi can produce. First of all it seems the only good debug info source on the Delphi side is the MAP file and the format of that seems a bit unstable. However since it's a text file it should be easy to adapt to any changes in it. Then there's the PDB file format. The only good and reliable documentation of that appears to be what the LLVM project has produced. Microsoft at one time published some of their source code for dealing with PDB files but since then the repository appears to have gone into limbo and they have not kept it up to date like they said they would. Anyway, in short, a PDB file is a MSF container file consisting of a number of streams containing the different debug info in CodeView format. The MSF format is pretty simple and since I only need to produce PDBs I don't need to bother about decoding MSF files. That leaves the PDB CodeView streams. Thanks to the LLVM documentation their format are known. However, after reading the LLVM source, it has become clear that it would be a huge task to implement all the different stream formats and all the different data types. I guess one could get by with a subset but it doesn't really seems worth the effort to create something that only works sometimes. The biggest problem however is that I would be implementing something based on a port of a third party's interpretation of Microsoft's old (and by now out of date) source. PDB is an internal VS format and Microsoft has stated that it can, and mostly will, change with each new version of VS. For this reason they provide the Debug Interface Access API for those that need to read PDB files. Unfortunately there's no (known) corresponding API to write PDB files. PDB support is important for the LLVM project (they too would like VTune to work with their output ) so they appear to be trying to keep up with the PDB changes and since they obviously have more resources for that task than I do I've decided to aim for a solution that piggybacks on their work instead of rolling my own. The solution I'm going to try is to parse the MAP file in Delphi, write out the relevant information in YAML format and then use the LLVM llvm-pdbtil tool to convert the YAML to PDB. Sounds easy and it probably would be except for the fact that the required YAML format is undocumented... The llvm-pdbutil yaml2pdb documentation does a handwave with "The YAML syntax is not described here. Instead, use llvm-pdbutil pdb2yaml and examine the output for an example starting point.". Lazy bastards Anyway, this was just a dump of the information I've been able to gather on the topic of generating PDB from Delphi in case I burn out before completing anything usable.

I have a feeling Vincent might already have code that does this from "some of his other projects" 🙂

Some more stuff you might not be aware of WRT critical sections_ https://devblogs.microsoft.com/oldnewthing/20140911-00/?p=44103 http://joeduffyblog.com/2006/12/14/anticonvoy-locks-in-windows-server-2003-sp1-and-windows-vista/ A spin count of 100 seems very low - but then again I don't know what your threads are doing and I don't really have time to look at your code to see what problem (if any...) you are trying to solve.

Instead of preconstructing the different formats so they are ready when the drag start, you could defer the creation and have the drop target initiate the creation when it requests the data. If it only takes ~2 seconds to create the data then that shouldn't be much of a problem and that also solves the problem of when to delete the source data; Delete it when the target closes the source stream - or if the drop is synchronous, when the drop completes. The D&D Suite has several examples that uses this technique... 🙂

You wish. The Delphi compiler doesn't optimize at that level.

Not sure what you're asking but: https://docs.microsoft.com/en-us/windows/win32/hidpi/setting-the-default-dpi-awareness-for-a-process https://docs.microsoft.com/en-us/windows/win32/sbscs/application-manifests#dpiaware

Did you start by reading the help?

You are writing your own spinlock to get better performance - and then you use Sleep() which is guaranteed to cause a context switch...? Unless you really know what you're doing then you better of using the synchronization primitives provided by the OS. https://devblogs.microsoft.com/oldnewthing/20051004-09/?p=33923 http://joeduffyblog.com/2006/08/22/priorityinduced-starvation-why-sleep1-is-better-than-sleep0-and-the-windows-balance-set-manager/ Apparently this can't be repeated often enough.

For example a TMultiReadExclusiveWriteSynchronizer.

I'm using Documentation Insight to generate MSDN-style API documentation. It does pretty much the same as PasDoc but I prefer the format/style of the Documentation Insight output. It also has IDE integration so I can edit the documentation inside Delphi and best of all (for me); It can optionally keep the documentation text external so I don't make the source unreadable.

I've never been in contact with Lasse (the original author) but as far as I remember the pieces of SynEdit that I found were significant enough that I could recognize them as coming from SynEdit. As far as I remember it was some of the syntax definitions. I don't know what interaction other people have had with him so I can't speak to that. The code copied might have been trivial and it might not have been that much but I still don't think it's acceptable to remove the license/attribution header and keep the code. Anyway, it's nothing compared to what Niels Hoyer did after he forked the code so regardless of SynEdit/TBCEditor the current TBCEditor forks are definitely in violation of Lasse's copyright. It's a damned pity as the code looked really promising but I can sympathize with Lasse burning out over the amount of pure crazy directed at him.

TBCEditor is: In violation the SynEdit license since portions have been copied directly from the SynEdit source but the attribution and all of the copyright and license references has been removed. Buggy as hell. The original repository was hijacked, after the original developer abandoned the project, but later deleted as the hijacker also abandoned it. Abandonware. Don't promote it.

Don't quit your day job.

Alternative to what?

3. Leave things as-is but educate the developers of the problem so they don't fall into this trap. I don't know what you criteria for "best" is but, if you have to, use whatever fits the individual case where this occurs. There doesn't need to be One True Way to solve this.

http://b2xtranslator.sourceforge.net/index.html Open Source. Written in C++. Precompiled binaries available.

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.