|
Hmmm,
I am on a canary build so it's entirely possible that I have additional features. Can you do me a favor and download a .MHT Sample File[^]
After downloading it shift-right-click and choose 'Open With' and browse to the Edge executable.
OriginalGriff wrote: It's possible that prior to the new Chromium version it did
I am on a canary build of Chromium-Edge. I am able to open MHT and MHTML files. I can also save pages as MHTML single file.
Best Wishes,
-David Delaune
|
|
|
|
|
Interesting: If I download that it opens OK in Edge.
So Outlook generates MHT files that aren't actually compatible? 
"I have no idea what I did, but I'm taking full credit for it." - ThisOldTony
"Common sense is so rare these days, it should be classified as a super power" - Random T-shirt
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
OriginalGriff wrote: it opens OK in Edge
I thought it would. 
OriginalGriff wrote: So Outlook generates MHT files that aren't actually compatible?
I can't imagine why it would generate anything different, MHTML is actually a standard documented in RFC 2557[^]
Best Wishes,
-David Delaune
|
|
|
|
|
Randor wrote: I can't imagine why it would generate anything different, MHTML is actually a standard documented in RFC 2557[^]
Are we not speaking about Microsoft?  
M.D.V. 
If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about?
Help me to understand what I'm saying, and I'll explain it better to you
Rating helpful answers is nice, but saying thanks can be even nicer.
|
|
|
|
|
I'm not an expert in the area of MHTML file formats but I would hazard a guess that the display problem @OriginalGriff is having is caused by Outlook generating a MHT file with the MIME type set to 'Content-Type: text/plain'.
The reason it opens in IE11 is an operating system team build issue. The OS image needs to change the default value of HKEY_CLASSES_ROOT\CLSID\{3050F3D9-98B5-11CF-BB8200AA00BDCE0B}\InProcServer32 which currently defaults to an apartment threaded (IE11) C:\Windows\System32\mshtml.dll
A COM object wrapper for launching Chromium-Edge does not exist yet, so don't expect any changes anytime soon.
|
|
|
|
|
Randor wrote: I would hazard a guess that the display problem @OriginalGriff is having is caused by Outlook generating a MHT file with the MIME type set to 'Content-Type: text/plain'.
If Outlook is opening the user's default app for MHT files then the MIME type is surely irrelevant. The MIME type would only matter if there was a HTTP connection which should surely not apply to this case.
Randor wrote: The reason it opens in IE11 is an operating system team build issue. The OS image needs to change the default value of HKEY_CLASSES_ROOT\CLSID\{3050F3D9-98B5-11CF-BB8200AA00BDCE0B}\InProcServer32 which currently defaults to an apartment threaded (IE11) C:\Windows\System32\mshtml.dll
A COM object wrapper for launching Chromium-Edge does not exist yet, so don't expect any changes anytime soon.
Good grief, surely not. That would mean that Outlook is massively over-complicated things. Windows has a simple mechanism that supports the necessary default app functionality without needing a COM wrapper for Edge!
See HKCU\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\FileExts. This contains subkeys that contain user choices for default apps for the specified filetypes. If the filetype is not found as a subkey of this key (meaning that the user has never made a choice) then the fallback is via HKCR\<.extension>. The default value of this key will point to another key in HKCR (e.g. by default ".mht" points to "mhtmlfile") that contains a "shell" subkey that eventually contains the command line necessary to open the file type in question.
New apps can register themselves as supporting specific capabilities using the HKLM\SOFTWARE\RegisteredApplications and HKCU\SOFTWARE\RegisteredApplications keys. The Capabilities keys pointed to by each app's entry in both RegisteredApplications allow users to choose default apps for specific file types and protocols in the Settings app. The user's personal choices are recorded in HKCU\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\FileExts (for file types) and HKCU\SOFTWARE\Microsoft\Windows\Shell\Associations\UrlAssociations (for protocols)[1].
No COM should be needed at all.
Does Outlook really try to use COM in this scenario?
Footnote:
1: It irks me that Microsoft mis-used protocols to open Microsoft Shop/Metro apps. This means that each app requires a new protocol to be added, which does not make semantic sense. Microsoft should have created a new mechanism (perhaps encapsulated within a single "ms-shop-app-runner" protocol for backward compatibility) for Shop/Metro apps. Or, you know, just let Metro apps be run from a command line.
|
|
|
|
|
yeah,
It's seriously too early in the morning to be reading all that.
markrlondon wrote: MIME type is surely irrelevant.
Sounds like you are one of those guys that think that when you download an EXE, AVI, MP3 or whatever that the browser decides what to do... based on the file extension. That would be wrong, browsers use a MIME type sent by the webserver to determine what to do with the file. MHT/MHTML files have a MIME type. (I am leaving out MIME sniffing for brevity)
markrlondon wrote: Good grief, surely not.
You say this then give an accurate (and very good) description of how MHT files would be opened. Which results in the same default HKEY_CLASSES_ROOT\CLSID\{3050F3D9-98B5-11CF-BB8200AA00BDCE0B} handler being invoked provided he hasn't overridden the ftype handler. You are saying the same thing as me here.
markrlondon wrote: No COM should be needed at all.
You have no idea how much COM is used in Windows. It's not going away. After an internal review it was decided COM is actually a good/stable framework and we built new system services in Windows 10 on top of it.
Best Wishes,
-David Delaune
|
|
|
|
|
Randor wrote: Sounds like you are one of those guys that think that when you download an EXE, AVI, MP3 or whatever that the browser decides what to do... based on the file extension. That would be wrong, browsers use a MIME type sent by the webserver to determine what to do with the file. MHT/MHTML files have a MIME type. (I am leaving out MIME sniffing for brevity)
No, I am the kind of guy who understands the context and realises that downloading via HTTP has nothing whatsoever to do with what is happening here.
For the avoidance of doubt, the context here is that Outlook (the local program I understand, see my postscript) has already received an email and is storing it locally for viewing. When the user clicks to view it in a browser, the email is saved as a MHT file locally and a web browser is opened to view the local file.
There is no download. HTTP is not involved. MIME types are not involved.
This is (or should be) a purely a non-COM shell operation.
In terms of which web browser (or other program) is opened to view the locally saved MHT file, it depends on how Outlook chooses to do it. There are two ways that do not require COM at all. (1) It could pass the path of the MHT file to the shell and allow the Windows shell to open whatever program is associated with MHT files. The file extension counts, not the MIME type (there is no MIME type in this scenario). By default, Internet Explorer is still the default handler for MHT file extensions. (2) Or Outlook could look up the associated program in the registry and then explicitly run the program, passing the MHT file to the program on the command line (again, no MIME type is involved).
Neither of these approaches needs or uses COM. These are the ways that most software uses to pass a file to another program for opening in my experience.
Randor wrote: You say this then give an accurate (and very good) description of how MHT files would be opened. Which results in the same default HKEY_CLASSES_ROOT\CLSID\{3050F3D9-98B5-11CF-BB8200AA00BDCE0B} handler being invoked provided he hasn't overridden the ftype handler. You are saying the same thing as me here.
The CLSID is not used -- or certainly *should* not be used. It is irrelevant in this context. COM is irrelevant in this context. You do not need COM to either pass a file to the Windows shell to be opened by another program or to run a program and pass a file path to it on the command line.
I did not mention COM or the CLSID key in my "very good" description of how a program usually passes a file to another program for opening via the shell because COM and the CLSID key are utterly irrelevant to this process, or should be irrelevant. They aren't needed.
Yes, I am sure that it is possible to run a program and pass it a file to open using what remains of DDE or what there is of COM (in which case you'd need the CLSID key of course) but it is completely unnecessary in this context. It would add complication for no benefit. There is no need to do it. The Windows shell provides a complete mechanism that utterly avoids any recourse to COM in this context. Most programs neither need COM to do this nor use COM to do this.
Randor wrote: You have no idea how much COM is used in Windows. It's not going away. After an internal review it was decided COM is actually a good/stable framework and we built new system services in Windows 10 on top of it.
(a) More to the point, I know when COM does not or should not have anything to do with the issue at hand.
(b) I have said nothing either for or against COM because it is unnecessary and irrelevant in this context.
(c) If by "we" you mean you work for Microsoft, then you should surely be more aware of how programs in real life on Windows can pass a file to another program using the shell but without touching, using, or needing COM to do it.
Try it... I have. I've never written anything as err... 'clever' as Outlook but I have written Windows software that both calls other programs to handle a file and receives files at the command line from other programs, and in no cases did I ever use or need COM! In other words, I have directly matched the scenario in question here. One program can trivially run another program and pass it a file to be opened, even if the CLSID key of the target program has been deleted or never existed at all. This is because COM is just not needed in this context. COM need not be used to open the target program. Opening at the command line is all that is needed and the required information is stored in the registry (as I described) for precisely this (non-COM-related) purpose.
P.S. When you wrote "I would hazard a guess that the display problem @OriginalGriff is having is caused by Outlook generating a MHT file with the MIME type set to 'Content-Type: text/plain'", were you thinking it was online Outlook? I rather think @OriginalGriff was referring to the local program. This seems to me to perhaps be why you thought that the MIME types and HTTP downloads were involved when they are not (assuming from the context that he did mean the local program).
modified 6-Oct-20 11:55am.
|
|
|
|
|
"MHT" literally means MIME hyper text.
MHT RFC MIME[^]
Don't bother responding, I am not going to debate you over this.
|
|
|
|
|
Randor wrote: "MHT" literally means MIME hyper text.
MHT RFC MIME[^]
Yes, MHT does mean MIME HTML. Well done.
However...
As RFC2557 (one of the RFCs you indirectly linked to) specifies, MHT/MHTML files are aggregate documents that can contain a serialised or archived HTML page including subsidiary components. As such, MHT/MHTML is essentially identical to the EML format.
Why is this relevant?
Because, in the context of the OP's question, a mail client program (such as Outlook) can save the content of an email into a MHT file so that the content can be viewed locally in a web browser or other program that supports the MHT/MHTML/EML format.
When the content is saved locally for viewing in such a manner, no MIME type is involved in terms of opening the target program. Let me say that again in slightly different terms: Even though the word "MIME" is part of the name "MHT" or "MHTML", it is still the case that no MIME type is involved in allowing a source program to open a target program to open the file via the shell. Only the file extension matters in this context. The Windows shell knows nothing of the MIME type of a file when a file is being passed from a source program to a target program to be opened.
I note also that you did not address the issue that COM is not needed in the context of the subject at hand: That of one program opening another to handle a file via the Windows shell.
|
|
|
|
|
markrlondon wrote: open a target program to open the file via the shell.
1.) Outlook is not opening MHT files via the shell.
2.) There is no default handler for MHT file extensions in the Windows operating system.
3.) Outlook is invoking the Outlook MHTML protocol handler which is written as a COM component.
Outlook MHTML protocol handler[^]
Best Wishes,
-David Delaune
|
|
|
|
|
Randor wrote: 1.) Outlook is not opening MHT files via the shell.
[...]
3.) Outlook is invoking the Outlook MHTML protocol handler which is written as a COM component
In that case I accept that we have been speaking at cross purposes. From @OriginalGriff's original message I was under the impression that Outlook was simply saving the email as a MHT file in some temporary location and then invoking whatever was the user's current default MHT handler in the shell to view the file.
Indeed, if Outlook says "click here to open in your browser" then this is, indeed, the behaviour I would expect: That is to open in the browser currently set to handle MHT files, not in Outlook's own protocol handler.
Randor wrote: 2.) There is no default handler for MHT file extensions in the Windows operating system.
Eh? Yes, there is. As of when I last checked, out of the box in Windows 10, Internet Explorer is registered as the default handler in the shell for .MHT and .MHTML files. I'll check this on a fresh install right now and confirm.
modified 6-Oct-20 12:52pm.
|
|
|
|
|
markrlondon wrote: we have been speaking at cross
You seem to have an argumentative personality. This XKCD[^] pretty much sums it up. There was no reason to have this long debate over this trivial matter.
markrlondon wrote: I'll check this on a fresh install right now and confirm.
interesting, keep me informed of your mind-bending discoveries. You should investigate the ftype command[^] while you are learning how to use the operating system.
Best Wishes,
-David Delaune
|
|
|
|
|
Randor wrote: You seem to have an argumentative personality
ROFL! And it looks to me like you are projecting. 
modified 6-Oct-20 13:34pm.
|
|
|
|
|
markrlondon wrote: Randor wrote: 1.) Outlook is not opening MHT files via the shell.
[...]
3.) Outlook is invoking the Outlook MHTML protocol handler which is written as a COM component
In that case I accept that we have been speaking at cross purposes. From @OriginalGriff's original message I was under the impression that Outlook was simply saving the email as a MHT file in some temporary location and then invoking whatever was the user's current default MHT handler in the shell to view the file.
Indeed, if Outlook says "click here to open in your browser" then this is, indeed, the behaviour I would expect: That is to open in the browser currently set to handle MHT files, not in Outlook's own protocol handler.
Actually I've just this second tested this in Outlook 2019 and I was right all along!: When I click 'View in Browser', Outlook saves the email as a MHT file (in my case in "C:\Users\myname\AppData\Local\Microsoft\Windows\INetCache\Content.Outlook\VPRZWED6\email.mht") and then runs the browser currently set in the shell as the .MHT handler to view the file. On my machine, since I have never changed the default browser for MHT files, this is Internet Explorer.
If Outlook is still using the Outlook MHTML COM component in some way to do this, it is complicating it enormously. Such a component is completely unnecessary in this context (and the use of COM to open the browser is also unnecessary). It could all by done without COM, as most other programs do it.
markrlondon wrote: I'll check this on a fresh install right now and confirm.
Am still downloading the latest W10 Enterprise trial.
|
|
|
|
|
 markrlondon wrote: markrlondon wrote: Randor wrote: 1.) Outlook is not opening MHT files via the shell.
[...]
3.) Outlook is invoking the Outlook MHTML protocol handler which is written as a COM component
In that case I accept that we have been speaking at cross purposes. From @OriginalGriff's original message I was under the impression that Outlook was simply saving the email as a MHT file in some temporary location and then invoking whatever was the user's current default MHT handler in the shell to view the file.
Indeed, if Outlook says "click here to open in your browser" then this is, indeed, the behaviour I would expect: That is to open in the browser currently set to handle MHT files, not in Outlook's own protocol handler.
Actually I've just this second tested this in Outlook 2019 and I was right all along!: When I click 'View in Browser', Outlook saves the email as a MHT file (in my case in "C:\Users\myname\AppData\Local\Microsoft\Windows\INetCache\Content.Outlook\VPRZWED6\email.mht") and then runs the browser currently set in the shell as the .MHT handler to view the file. On my machine, since I have never changed the default browser for MHT files, this is Internet Explorer.
Furthermore, I have just selected Edge (Chromium Edge) as the default handler for both .MHT and .MHTML files and I can now replicate @OriginalGriff's problem: Edge shows a plain text rendition of the file whereas the very same file opened in Internet Explorer is rendered properly.
The problem is nothing to do with COM or anything like it. (Blame it on the MHTML COM component which I can see may well be used to generate the MHT files, if you want, but the actual problem is still nothing to do with COM. And the browser is not being opened via COM and COM is not used to pass the file to open).
I've done some more testing and the problem is within Edge's interpretation of .MHT files. When I use Outlook's 'View in Browser' option, it generates a MHT file that Internet Explorer can render correctly whereas Edge cannot. When I use Thunderbird to save the same email to a MHT file, I get the same end result: Internet Explorer can successfully render the file whereas Edge shows me a text rendition instead.
Chromium Edge can, however, successfully render MHT files saved from browsers: I have tested MHT files saved from Chromium Edge itself, Internet Explorer, Firefox with UnMHT, and Waterfox with UnMHT, and they are all rendered successfully in both IE and Edge.
So there is something about emails saved as MHTs that Edge can't render properly. I'll investigate this more and report back.
I'd also like to re-iterate that Outlook really does appear to be doing what I thought it was all along: It is saving the email as a MHT file to the file system (as above) and then running the user's currently set MHT handler to open it.
modified 6-Oct-20 14:13pm.
|
|
|
|
|
markrlondon wrote: I've done some more testing and the problem is within Edge's interpretation of .MHT files. When I use Outlook's 'View in Browser' option, it generates a MHT file that Internet Explorer can render correctly whereas Edge cannot. When I use Thunderbird to save the same email to a MHT file, I get the same end result: Internet Explorer can successfully render the file whereas Edge shows me a text rendition instead.
Chromium Edge can, however, successfully render MHT files saved from browsers: I have tested MHT files saved from Chromium Edge itself, Internet Explorer, Firefox with UnMHT, and Waterfox with UnMHT, and they are all rendered successfully in both IE and Edge.
So there is something about emails saved as MHTs that Edge can't render properly. I'll investigate this more and report back.
I'd need to hand-craft some MHT files to test this more fully but it looks to me as if Edge cannot properly render MHTs with a primary Content-Type of multipart/alternative. If the first alternative sub-part is text/plain then it renders that and not the alternative text/html version.
Internet Explorer, on the other hand, correctly renders the text/html alternative in a MHT that has a multipart/alternative primary type (and ignores the text/plain alternative).
Most MHTs saved from browsers, however, have a primary type of 'multipart/related; type="text/html"' which both IE and Edge can successfully render.
I wonder if this is a bug or a deliberate design choice in Edge.
Either way, it's nothing to do with registered COM objects. The bug is not in Outlook or the MimeOLE component.
|
|
|
|
|
markrlondon wrote: Edge cannot properly render MHTs with a primary Content-Type of multipart/alternative.
Are you aware that you literally spent the last 24 hours arguing that MIME types were not involved? Now you're telling me that you have discovered that the MIME (Content-Type) is causing the problem.
Why do you find this topic so important? After discovering that MIME types are indeed what's causing the issue, go back and read your previous statements.
|
|
|
|
|
Randor wrote: Are you aware that you literally spent the last 24 hours arguing that MIME types were not involved? Now you're telling me that you have discovered that the MIME (Content-Type) is causing the problem.
(a) I stated that MIME types were not involved in a source program selecting which target program to open for a particular file. I was and am completely correct. It is indeed the case that MIME types are not involved in any way, shape or form in the process of a source program finding the correct target program to open a particular file type via the shell.
(b) I am now pointing out that the value of the primary Content-Type header of MHT files marks a difference between how Internet Explorer and Edge render MHT files. This is new information. It could well be a bug in Edge.
Got it now?
Randor wrote: Why do you find this topic so important?
I must bring to your attention the fact that you are choosing to discuss this with me. Why is it so important to you?
After discovering that MIME types are indeed what's causing the issue, go back and read your previous statements.
My previous statements were and are completely correct. Read over them again. As I noted above in this message (and as I have said all along), MIME types have no connection whatsoever with a program such as Outlook opening a program such as a web browser to display a MHT file that Outlook has saved in the file system. And yes, despite your incorrect claims to the contrary, Outlook does save the MHT file in the file system.
Only the file extension defines what the target program should be in this scenario, not its MIME type. You incorrectly claimed that MIME types were involved in this process (seemingly, as far as I can tell, because you thought it was a HTTP download issue and not a shell issue).
A wholly new discovery (to you too, I hope you don't try to pretend otherwise) is that the reason for @OriginalGriff's reported bug is what seems to be an error in Edge's processing of MHT files (when compared to Internet Explorer). Whilst this is certainly to do with the MIME structure of MHT files it is still nothing to do with which target program is opened, which was the subject of my earlier comments about MIME types. As an aside, it also means that your analysis of the reason for the @OriginalGriff's error was wrong.
|
|
|
|
|
At least you are very good at debate. The technique you are using is called gish gallop[^]. A laymen reading this will not be able to determine which is author is correct. It would take a subject matter expert to look deeper.
Anyway, this is getting nowhere and I don't want to be a part of this anymore.
|
|
|
|
|
The "technique" I have used is to test reality versus both your claims and my own claims, and reality has shown that I was correct in what I said. I have done no more than to point this out, honestly, fully and thoroughly.
The records of what you and I have said are here for anyone and everyone to see. These issues are not matters of opinion where subjective views can legitimately differ. Instead, the issues under discussion are all objectively provable through empirical testing, one way or another. They can be tested in Outlook and in Windows, and I have actually done this and recorded the objective results in this thread. The results showed my claims to to correct.
And as part of my testing I discovered what seems to be a bug in Chromium Edge (compared to IE).
Anyone who is interested and who wishes to work through the debate can see all of this. This is a forum for software developers, afterall, so it should not be surprising that the issues are technical. Nevertheless, it's all there for anyone sufficiently interested.
|
|
|
|
|
I have reviewed my comments and cannot find anything incorrect in my response to the poster.
The Lounge[^]
The Lounge[^]
Can you highlight exactly which statement you believe is incorrect for me?
|
|
|
|
|
Sh!4, I admit it. Whilst you really did make mistakes, I made one too. Read on.
Here: 04/10/20 21:38, The Lounge[^] : You wrote that "I would hazard a guess that the display problem @OriginalGriff is having is caused by Outlook generating a MHT file with the MIME type set to 'Content-Type: text/plain'" and I rejected this as a possibility because I misread what you meant. I'm really sorry.
In fact you identified pretty much the exact bug I later found, except that as far as I can see it is a bug in Edge, not Outlook. Outlook (or MimeOLE) seems to me to create correct MHT files for emails and it is (or should be) up to Edge to replicate IE's behaviour by rendering the text/html part and not the text/plain part in such a MHT.[1]
Here is why I got the wrong end of the stick: You referred to the Content-Type header within the MHT file as "the MIME type" and for some reason I read it as if you were referring to the MIME type in a HTTP download. I completely got the wrong end of the stick on that.
I am really sorry about that. I should have been more cautious.
However, you did then go on to say that "The reason it opens in IE11 is an operating system team build issue" and that is certainly an error. The reason the MHT file opens in IE is because IE is the default handler for .MHT and .MHTML files. This is, as I said, nothing to do with COM. I fully appreciate that the CLSID you refer to in that message points to the component Outlook uses to generate the MHT file but it is absolutely not the reason that IE is then used to open the file.
You also went on to say that "A COM object wrapper for launching Chromium-Edge does not exist yet" but this would not in and of itself change anything in terms of IE still being the default handler for .mht/.mhtml files in the registry.
So, I apologise very humbly for getting the wrong end of the stick but you did make mistakes too. MIME is of course not used to select the target program to open a file but, I now realise, you never said it did!
On the other hand, I was right to say that COM was and is irrelevant to the way that IE or Edge are opened to view the saved MHT file.
Also you also went on to say in a later message that "Outlook is not opening MHT file via the shell" but, as I pointed out, it's the other way: Outlook demonstrably does save MHT files (generated by the COM component) to the file system and then uses the shell to run a target program to open the saved MHT file.
Anyway, I apologise for my error to begin with. We both made errors of fact and of interpretation.
Footnote:-
1: Just to recap the Edge bug for reference: As I went on to mention, Thunderbird creates MHT files with text/plain and text/html parts within a multipart/alternative structure exactly as Outlook/MimeOLE do, so I think it is Edge that needs to change to match IE's behaviour in terms of rendering the text/html part in a multipart/alternative structure. Both IE and Edge successfully render web pages saved by browsers into MHT files since these all seem to use multipart/related;type="text/html" structures instead.
** edit ** Fixed the message link.
modified 6-Oct-20 21:46pm.
|
|
|
|
|
markrlondon wrote: 2.) There is no default handler for MHT file extensions in the Windows operating system.
Eh? Yes, there is. As of when I last checked, out of the box in Windows 10, Internet Explorer is registered as the default handler in the shell for .MHT and .MHTML files. I'll check this on a fresh install right now and confirm.
Just checked with a fresh install of the trial version of W10 Enterprise 2004 and, yes, there is a default handler for .MHT and .MHTML files in Windows 10 and, as I said, it is Internet Explorer.
Here are the relevant parts from the registry:
[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\.mht]
@="mhtmlfile"
[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\.mhtml]
@="mhtmlfile"
[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\mhtmlfile\DefaultIcon]
@=%ProgramFiles%\Internet Explorer\iexplore.exe,-32554
[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\mhtmlfile\shell\open\command]
@="\"C:\\Program Files\\Internet Explorer\\iexplore.exe\" %1"
Or if you prefer the output of ftype:
>ftype mhtmlfile
mhtmlfile="C:\Program Files\Internet Explorer\iexplore.exe" %1
|
|
|
|
|
Heh,
I have not confirmed it, but I believe you. Congratulations, you found one thing I said that might not be correct. This is funny, you are picking through everything I say looking for at least one thing I say that might be wrong. I have never had anyone do this to me, I can't figure out your motivation. This is a very unpleasant experience.
I can tell you that the older that I get (I am an old man) I expect to be wrong more often. But as an experienced software engineer that contributed to Windows 8,8.1, and 10 at Microsoft in the operating systems group I hope that I can contribute and help others here on codeproject.com and have a positive impact. I try to avoid conflict and I try to share my experience and wisdom with others.
Best Wishes,
-David Delaune
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
