|
EULA's under CP'w license are fair and simple;
But some are beyond what is fair, and most go beyond simple.
This world predatory.
Bastard Programmer from Hell 
"If you just follow the bacon Eddy, wherever it leads you, then you won't have to think about politics." -- Some Bell.
|
|
|
|
|
Nobody reads them, say as NDA's and so forth.
My standard NDA pre 2000 included the ritual sacrifice of the first born child as a penalty for disclosure, but it was always signed without comment or revision.
I even got asked to sign a NDA that had been copied from it at one point. 
"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: My standard NDA pre 2000 included the ritual sacrifice of the first born child as a penalty for disclosure
To which god(s)?
Freedom is the freedom to say that two plus two make four. If that is granted, all else follows.
-- 6079 Smith W.
|
|
|
|
|
I didn't specify ... leaves more scope for creativity!
"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!
|
|
|
|
|
I once read about a guy who changed his mortgage contract, signed it and then sent it back to the bank, who also signed it without reading.
He changed it so he got negative rent and such, which of course he didn't get.
Either one sued the other, but I can't say who won 
|
|
|
|
|
I don't; any agreement that's agreed upon under misconception, deception or fraud is not an agreement in legal terms; it simply doesn't count as "agreeing". It's one of the basic concepts. 1
Everyone clicks "I agree", since we not lawyers and hardly understand the legal bullshit, but we need to click there to get access to the product we actually paid for.
We all ignore it, because their "terms" are worth de nada. They present jargon to use what you paid for. Everyone says "I agree". Misleading agreements are no agreements. So, we not bound to it; it is a form of legal intimidation, but nothing more. Those agreements are void.
Bastard Programmer from Hell
"If you just follow the bacon Eddy, wherever it leads you, then you won't have to think about politics." -- Some Bell.
|
|
|
|
|
Yeah, that's the other part I didn't want to get into - I think the common agreement is that EULAs are generally non-enforceable.
My point was one of morbid curiosity however - trying to immediately spot what it is they try to sneak in over time. If the changes are brought to focus, it's easier to see where they're coming from, and from that, make up your own mind about the company.
|
|
|
|
|
I am altering the deal. Pray I don't alter it any further.
|
|
|
|
|
Just had an email from Amazon Prime - and Outlook (rightly) blocked the images to prevent phishers getting a "live email address" indicator.
Trouble is, Prime emails are all pictures, so I have no idea what has "Just arrived on Prime Video".
No hassle - there is a "click here to open in your browser" ribbon kindly provided by Outlook for just such occasions. Click it.
"Are you sure? The security settings will not be the same". Yes.
So it ... opens it in IE11 ... 
So a moments thought tells me why: Outlook looks at the email in HTML and packages it in a MHT file and uses the default app to open those via Process.Start (or similar). Unfortunately, neither Chrome nor Edge support MHT files anymore, so it digs up the oldest browser it can find on the computer and uses that ...
So MS's recommended email product produces a file that MS's recommended browser can't open any more ... that's joined up thinking at it's best, that is!
"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!
|
|
|
|
|
Oddly enough that happened to me a few days ago. I though it was just a glitch in something and ignored it.
|
|
|
|
|
Sounds like they need to update Outlook to produce a better file format. Knowing Microsoft, Outlook will continue to produce and consume MHT files long after the rest of the world has moved on.
Real programmers use butterflies
|
|
|
|
|
MHTs are a good file format. They work, are standardised, and supported. Outlook is doing the right thing by generating MHTs.
As I say in my other message, it would simply help if Outlook could alert the user to other MHT viewers available in the system. (Or even view its own MHTs, which it should be able to do given that they are standard EML files).
|
|
|
|
|
Yes, it's annoying when you click on "View in Browser" by mistake, instead of "Download Pictures".
|
|
|
|
|
-
OriginalGriff wrote: Unfortunately, neither Chrome nor Edge support MHT files anymore
Microsoft Edge does support MHT files.
Looks like an operating system build problem. The default protocol handler for {3050F3D9-98B5-11CF-BB82-00AA00BDCE0B} is here: HKEY_CLASSES_ROOT\CLSID\{3050F3D9-98B5-11CF-BB8200AA00BDCE0B}\InProcServer32
OriginalGriff wrote: that's joined up thinking at it's best
Fair assessment. The default browser for the operating system is currently in a transition period.
modified 4-Oct-20 13:36pm.
|
|
|
|
|
Randor wrote: Microsoft Edge does support MHT files.
You sure?
Just like Chrome, it opens it as raw text, and displays the HTML.
It's possible that prior to the new Chromium version it did, just like it used to support epub files.
But it doesn't now!
"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!
|
|
|
|
|
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.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
