Anders Melander

https://en.wikipedia.org/wiki/Interpreter_(computing)#Bytecode_interpreters

So you are doing it with Outlook which again prompts me to ask why you're not also handling the eml files the same way (after importing them into Outlook) instead of handling them in two different ways? Personally I would probably: Load the msg file into an IStorage with StgOpenStorage Get an IMessage from the IStorage with OpenIMsgOnIStg Extract the IMessage properties with HrGetOneProp or IMessage.OpenProperty

Yes I understood that. I was talking about your statement : "drop the msg files into Outlook and handle them there somehow".

If I'm understanding what you're saying you are going drop the msg files into Outlook and handle them there somehow. If that's an option then why not also handle the eml files this way?

I would guess that no other types use it. It's not a very friendly format. I can't speak authoritatively on the subject but if IMessage is a MAPI interface then in theory it should work with all MAPI providers. Unfortunately I don't think there's many applications left that support MAPI. I doubt it but it should be easy to determine since you have the source...

Outlook msg files are COM Structured Storage files in the CFB3 (Compound File Binary) format. Here's file file format specification: http://msdn.microsoft.com/en-us/library/cc463912.aspx You can use the IStorage interface to load the file (via IStream) but you will need to locate and extract the desired properties manually. You can find tons of code on the net that shows how to do that and I think the above specs contains the names of the properties. I also think the last version of the Drag and Drop Component Suite I released even contained some code that did it. AFAIR there's also an OpenIMsgOnIStg API function that can do some of the work for you but I think it might require that Outlook is installed.

Okay, here you go. Source and simple demo attached. Usage: Producer var FRingBuffer := TSharedMemoryRingBuffer.Create('FooBar', 1024*1024); // 1Mb ... // String FRingBuffer.Enqueue('Hello world'); // Raw bytes var Buffer: TBytes; ... FRingBuffer.Enqueue(Buffer); Consumer var FRingBuffer := TSharedMemoryRingBuffer.Create('FooBar', 1024*1024); // 1Mb ... // Strings while (True) do begin // Just remove the WaitFor to use polling instead if (FRingBuffer.WaitFor(100) = wrSignaled) then begin var s. string; if (FRingBuffer.Dequeue(s)) then ...do something with string... end; ... end; // Raw bytes while (True) do begin // Just remove the WaitFor to use polling instead if (FRingBuffer.WaitFor(100) = wrSignaled) then begin var Buffer: TBytes; if (FRingBuffer.Dequeue(Buffer)) then ...do something with buffer... end; ... end; amSharedMemory.pas SharedMemory.zip

@A.M. Hoornweg Thanks for the detailed explanation. I understand your challenge much better now. I think it's essential that you realize that the overhead of the lock itself is not going to be a factor at all and instead focus on minimizing the time the lock is held - i.e. the time to transfer data to and from the shared memory buffer. My recommendation would be to start with a simple solution and if that turns out not to be fast enough then you can try to come up with something better. I don't know anything about the actual amount of data you're processing but I think I would strive to process it in many small chunks instead of few large chunks. On the producer side I would write data packets to a (fast) lock free queue and have a separate thread read from that queue and write them to the (slower) shared memory queue. If it's essential that the producer isn't blocked then you will have to accept that data can be dropped if the consumer isn't able to keep up, but I guess you already know that. Again, if you want it I have a ready to use implementation of a shared memory circular buffer that has been used in production for many, many years.

Are you kidding me? What you are asking for is apparently a wheelbarrow while the rest of us are suggesting different ways to build a drag racer I don't get why you don't just use a TMutex to protect the ring buffer structure and a TSemaphore to signal availability. I mean it's like around 10 lines of extra code compared to the 2-300 lines of code you will need to implement the ring buffer in shared memory. You're aware that you can't store pointers in shared memory, right?

So how will you use a spinlock to signal the consumer thread that data is available without doing busy wait?

And it's extremely subject to race conditions. https://devblogs.microsoft.com/oldnewthing/20160826-00/?p=94185

Why not just use the traditional synchronizations mechanism provided by the OS and keep things simple? It seems pointless focusing on micro optimizing the concurrency control of a buffer backed by virtual memory and accessed synchronously. The sync mechanism is not going to be the bottleneck. I have the code for a shared memory ring buffer somewhere if the OP is interested. I used it a few decades ago to pipe CodeSite log messages between a producer and a consumer service. The consumer wrote the log to disk.

Call me old fashioned but the way you've formatted your code makes it close to unreadable to me.

Instead of waiting on the back and forth I'll assume that what we have here is a classic case of the XY problem. To determine what properties a WMI object exposes you can use a tool like WMI Explorer (there are many other tools like that, this is just the first one I found).

Yes.

Those are just the WMI methods and they are all documented. https://docs.microsoft.com/en-us/windows/win32/api/wbemcli/nn-wbemcli-iwbemclassobject If you want to talk to a COM server why are you then going through WMI? Are you sure it isn't a WMI Provider you are talking about? If you install the Windows SDK (just the tools parts) there's a utility in it called OleView that you can use to examine type libraries and COM servers. The type library of your server is probably embedded in the EXE file. Edit: If it's a WMI provider then it's probably a DLL and it's probably early bound and without a type library. It depends on what kind of provider it is.

Maybe if you learned the difference between OLE and COM you wouldn't be so scared... Hardly anyone uses OLE anymore.

Storing a 31-bit value in a 64-bit intermediary doesn't magically produce more distinct values. You'll still have at most 2^31 distinct values.

Hey Reinier! I think it must be over 20 years since I last heard from you. AFAIR you were the original maintainer of The Delphi Bug List. Ah, yes: https://web.archive.org/web/20001025065121/http://www.dataweb.nl/~r.p.sterkenburg/indexpag.htm Good to see you're still around.

Most of them. You're scaling a 31-bit integer value in the approximate range 0..X-1 to the range 0..2^64-1 A lot of things wasn't mentioned. For example here's my solution which satisfies all the criteria that was mentioned: The result is 64-bit unsigned. It's cross platform. It compiles with FPC. It's random (for a large enough sample size). and as a bonus It's super fast. function SuperRandom: UInt64; begin Result := 1; end; (sorry - it's Friday)

Compatible with what?

You can ask @CrystalNet

Nope. I just use COM callable .NET wrappers. I would rather have the .NET code live in an external .NET assemble than introduce a dependency on a 3rd party library and have a dependency on .NET.

I like it for internal documentation. For external use I think it sucks as you can't style it properly. If we were to replace it I would probably just use WordPress. Oh... wow. I just read their announcement. For Jira, Confluence and Bitbucket this won't affect us much. Our Jira and Confluence are already on cloud. But for Bamboo this definitely means that we'll have to find alternatives and Bitbucket pipelines isn't a viable alternative. I just took their migration quiz. Bamboo isn't listed at all... and for Bitbucket it recommended that I migrate to Bitbucket Data Center - which is also being EOL'd.. Classic Atlassian.

Yeah, well Bamboo being an Atlassian product relies on paid 3rd party add-ins for even the simplest things It does have support for XMPP but that isn't supported by Teams.