In comp.mobile.android, on Fri, 2 Feb 2024 19:30:23 +0100, "Carlos E.R."
<robin_listas@es.invalid> wrote:

>On 2024-02-02 16:53, Peter Johnson wrote:
>> On Fri, 02 Feb 2024 10:01:46 -0500, micky <NONONOmisc07@fmguy.com>
>> wrote:
>>
>>> I thought I was installing Whatsapp on my PC just because that one
>>> airline insisted on my using it, but it turns out it's a really good
>>> thing.
>>
>> PC/Android users can use any app on the PC by installing Phone Link on
>> the PC and activating it on the phone. I find it very useful under the
>> conditions you described. If I connected a microphone I could answer
>> and make phone calls via the PC. Doesn't work if you switch the phone
>> off though.
>>
>> (Similar capabilities are available on Apple devices but I don't know
>> anything about them.)
>
>But this tool requires the phone to be running, whereas the whatsapp app
>(or the equivalent on the web browser) do not.

I misunderstood before, and repeated my misunderstanding in another post
in this thread. You wrote idiomatically (a weakness in the current
English vernacular) but you still mean: *and* the equivalent on the web
browser. And by golly you're right. I just sent texts with both
methods. This means I don't have to turn on my phone to to send, and I
think receive, texts, and it seems audio and video calls (though I have
not done either of those yet.) This is great.

Andy Burns wrote on Thu, 8 Feb 2024 19:09:46 +0000 :

>> What would be nice is if someone can look in their similar folder
>> C:\Users\user\AppData\Local\Apps\2.0\N0AR711Q.1VA\PRHK4WQY.TYG
>>
>> And let me know what other apps they have installed which turned
>> out to be one of these brand new but very strange "appref-ms" things.
>
> I have "C:\Users\Andy\AppData\Local\Apps\2.0\CX4NKDB8.9YL\2D70C5C9.D2W"
> but it's empty, apart from a manifests folder.

That's good to know. Thanks for checking. I am surprised you have it too.

However, with only two datapoints it's hard to surmise much, but I'm going
to guess that anyone with a similar folder has run across one of these new
fangled appref-ms "modern apps" that they don't want us to know about.
"C:\Users\username\AppData\Local\Apps\2.0\."

If only we knew what these new fangled "appref-ms" modern apps are...

On 2/8/2024 1:24 PM, Andrew wrote:
> Paul wrote on Thu, 8 Feb 2024 12:49:33 -0500 :
>
>> https://stackoverflow.com/questions/10766334/how-to-find-the-target-exe-file-of-appref-ms
>
> Yes. Thanks. I had already read that before I posted the question.
> You can see that link in the original post.
>
> I read every link found before I asked the question here.
> If I had found the answer on the Internet, I wouldn't have asked here.
>
> In particular, that link doesn't answer the question of what the thing is.
> It answers the question of how to find the executable which I did try.
>
>> It's apparently a ClickOnce App.
>
> What does that mean when EVERY app is a click once app.
> How's that different from a double click once app?
>
>> [Picture] ... of the stackoverflow page
>> https://i.postimg.cc/dV5Ld83L/click-once-appref.gif
>
> Yes. I saw that BEFORE I posted. It answers a different question.
> It's not asking what it is but where it went.
>
> I did look at where it went though, which is here.
> C:\Users\user\AppData\Local\Apps\2.0\N0AR711Q.1VA\PRHK4WQY.TYG\andr..tion_0000000000000000_0002.0000_0bbee2d2e624354e\AndroidMic.exe
> (and yes, those doubledots are really there, as can be seen here)
> https://i.postimg.cc/ZRn4VZdT/clickonce.jpg
>
> Apparently this strange appref-ms thing installed into an AppData folder.
> https://i.postimg.cc/Qxt11WtP/appdata.jpg
>
> Where if you dig down deep enough you finally find the executable.
> https://i.postimg.cc/rsdyFcVh/androidmic.jpg
>
> Doesn't this "appref-ms" thing from Microsoft seem strange to you?
>
>> Apps need the ability to update.
>
> All apps have the ability to update, whether they're click once or click
> twice apps. So that doesn't tell us anything.
>
>> sideload (winget)
>> App Store (microsoftstore)
>> ClickOnce (essentially a private store, for your updates)
>>
>> The appref-ms gives the ability to store a URL or similar,
>> and when the application starts, it checks for updates.
>
> All apps can do that.
> Whether or not they're these strange new Microsoft appref-ms things.
>
>> Otherwise, the App part works the usual ways, using its manifest
>> for loading, using certain (permission denied) areas for
>> component storage. This is what makes study of the construction,
>> searching for the gubbins, hard to do.
>>
>> You can always use nfi.exe to list the component parts.
>> That's how I'd do it, if I needed "component part" info.
>
> I don't have nfi.exe on my system as it's not native to Windows.
> But I googled for it and see that it's described over here.
> https://learn.microsoft.com/en-us/sysinternals/resources/archive/v02n05
>
> "Microsoft has released a free tool named NFI (NTFS Information) that
> understands and can dump the internal structures of NTFS volumes.
> You can download NFI as part of the OEM Support Tools at
> http://support.microsoft.com/support/kb/articles/q253/0/66.asp. Running NFI
> with a file name dumps the NTFS MFT record for that file."
>
> From that I can tell it's not going to explain to me in human
> understandable terms what these very strange new "appref-ms" files are.
>
> What would be nice is if someone can look in their similar folder
> C:\Users\user\AppData\Local\Apps\2.0\N0AR711Q.1VA\PRHK4WQY.TYG
>
> And let me know what other apps they have installed which turned
> out to be one of these brand new but very strange "appref-ms" things.
>

This is the only file on the test VM of that type, after installing AndroidMic there.

File 7089
\Users\Bullwinkle\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\Teamclouday\AndroidMic.appref-ms
$STANDARD_INFORMATION (resident) \
$FILE_NAME (resident) \
$FILE_NAME (resident) \____ Resident means, fits it lives in a 1024 byte $MFT slot, max 700 bytes or thereabouts
$DATA (resident) /

Had to get at it from WSL. In Windows, the extension will not display. Attempting to
edit the entry, just defaces the filename portion of filename.ext . However, from
WSL, I am "allowed" to display the real name. Now, we just cat it.

/mnt/d$ file AndroidMic.appref-ms
AndroidMic.appref-ms: Little-endian UTF-16 Unicode text, with no line terminators

This is the content.

file:///C:/Users/Bullwinkle/Downloads/release--androidmic/release/Windows/AndroidMic.application
#AndroidMic.application, Culture=en, PublicKeyToken=0000000000000000, processorArchitecture=msil

That points to a file in the unpacked installer directory I used. I'm guessing
it's a good idea to keep that folder around ?

AndroidMic.application 1,926 bytes

/mntd$ file AndroidMic.application
AndroidMic.application: XML 1.0 document, UTF-8 Unicode (with BOM) text, with very long lines, with CRLF line terminators

ClickOnce Application Support Library [ what opens a .application ]

<?xml version="1.0" encoding="utf-8"?>
<asmv1:assembly xsi:schemaLocation="urn:schemas-microsoft-com:asm.v1 assembly.adaptive.xsd"
manifestVersion="1.0" xmlns:asmv1="urn:schemas-microsoft-com:asm.v1"
xmlns="urn:schemas-microsoft-com:asm.v2" xmlns:asmv2="urn:schemas-microsoft-com:asm.v2"
xmlns:xrml="urn:mpeg:mpeg21:2003:01-REL-R-NS" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:asmv3="urn:schemas-microsoft-com:asm.v3" xmlns:dsig="http://www.w3.org/2000/09/xmldsig#"
xmlns:co.v1="urn:schemas-microsoft-com:clickonce.v1" xmlns:co.v2="urn:schemas-microsoft-com:clickonce.v2">
<assemblyIdentity name="AndroidMic.application" version="2.0.0.0" publicKeyToken="0000000000000000"
language="en" processorArchitecture="msil" xmlns="urn:schemas-microsoft-com:asm.v1" />
<description asmv2:publisher="Teamclouday" asmv2:product="AndroidMic"
asmv2:supportUrl="https://github.com/teamclouday/AndroidMic" xmlns="urn:schemas-microsoft-com:asm.v1" />
<deployment install="true" mapFileExtensions="true" />
<compatibleFrameworks xmlns="urn:schemas-microsoft-com:clickonce.v2">
<framework targetVersion="4.7.2" profile="Full" supportedRuntime="4.0.30319" />
</compatibleFrameworks>
<dependency>
<dependentAssembly dependencyType="install"
codebase="Application Files\AndroidMic_2_0_0_0\AndroidMic.exe.manifest" size="18338">
<assemblyIdentity name="AndroidMic.exe" version="2.0.0.0" publicKeyToken="0000000000000000"
language="en" processorArchitecture="msil" type="win32" />
<hash>
<dsig:Transforms>
<dsig:Transform Algorithm="urn:schemas-microsoft-com:HashTransforms.Identity" />
</dsig:Transforms>
<dsig:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha256" />
<dsig:DigestValue>mdsUreDH9SUF2xFb6Ig86FKgRB5EKoH9N6udG3uWHrk=</dsig:DigestValue>
</hash>
</dependentAssembly>
</dependency>
</asmv1:assembly>

[Picture] Runtime behavior...

https://i.postimg.cc/fknYTv9g/androidmic-startup.gif

Paul

Paul wrote:

> https://i.postimg.cc/fknYTv9g/androidmic-startup.gif

Ah, that's the second stretched image you've posted recently, the first
time was the screenshot of disk manager you managed to extract as a
binary attachment for someone, so I assumed it was an artefact of having
to piece the image back together, and didn't mention it.

But this one is a screenshot from your own system, it works ok if I
click to zoom the image, but postimage is badly mangling the non-zoomed
version ...

On 2/8/2024 10:03 PM, Andy Burns wrote:
> Paul wrote:
>
>> https://i.postimg.cc/fknYTv9g/androidmic-startup.gif
>
> Ah, that's the second stretched image you've posted recently, the first time was the screenshot of disk manager you managed to extract as a binary attachment for someone, so I assumed it was an artefact of having to piece the image back together, and didn't mention it.
>
> But this one is a screenshot from your own system, it works ok if I click to zoom the image, but postimage is badly mangling the non-zoomed version ...

Correct.

In all cases, you must use your "craft" to get something
from the exercise.

Unfortunately.

The other sites I might use, also present challenges,
so it's not like any site is "righteous".

"Download original image" is available as an option,
no matter how they degrade the default image.

Paul

On Sat, 10 Feb 2024 16:13:30 -0500, Paul <nospam@needed.invalid> wrote:

>On 2/8/2024 10:03 PM, Andy Burns wrote:
>> Paul wrote:
>>
>>> https://i.postimg.cc/fknYTv9g/androidmic-startup.gif
>>
>> Ah, that's the second stretched image you've posted recently, the first time was the screenshot of disk manager you managed to extract as a binary attachment for someone, so I assumed it was an artefact of having to piece the image back together, and didn't mention it.
>>
>> But this one is a screenshot from your own system, it works ok if I click to zoom the image, but postimage is badly mangling the non-zoomed version ...
>
>Correct.
>
>In all cases, you must use your "craft" to get something
>from the exercise.
>
>Unfortunately.
>
>The other sites I might use, also present challenges,
>so it's not like any site is "righteous".
>
>"Download original image" is available as an option,
>no matter how they degrade the default image.

If things get bad enough with the image hosting sites, we might have to go back
to how we did it for 30 years - by posting the image to Usenet, typically to a
garbage group such as alt.binaries.test, and including the MID in the text post.
I assume most, if not all, NNTP clients know how to open a MID. The downside is
that you lose the advertising that comes with the web-based sites.

On 2/10/2024 8:41 PM, Char Jackson wrote:
> On Sat, 10 Feb 2024 16:13:30 -0500, Paul <nospam@needed.invalid> wrote:
>
>> On 2/8/2024 10:03 PM, Andy Burns wrote:
>>> Paul wrote:
>>>
>>>> https://i.postimg.cc/fknYTv9g/androidmic-startup.gif
>>>
>>> Ah, that's the second stretched image you've posted recently, the first time was the screenshot of disk manager you managed to extract as a binary attachment for someone, so I assumed it was an artefact of having to piece the image back together, and didn't mention it.
>>>
>>> But this one is a screenshot from your own system, it works ok if I click to zoom the image, but postimage is badly mangling the non-zoomed version ...
>>
>> Correct.
>>
>> In all cases, you must use your "craft" to get something
>>from the exercise.
>>
>> Unfortunately.
>>
>> The other sites I might use, also present challenges,
>> so it's not like any site is "righteous".
>>
>> "Download original image" is available as an option,
>> no matter how they degrade the default image.
>
> If things get bad enough with the image hosting sites, we might have to go back
> to how we did it for 30 years - by posting the image to Usenet, typically to a
> garbage group such as alt.binaries.test, and including the MID in the text post.
> I assume most, if not all, NNTP clients know how to open a MID. The downside is
> that you lose the advertising that comes with the web-based sites.
>

Yes, on E-S there is a group for that purpose.

However, depending on the size of the picture (I can do 10000 x 10000 on PostImage),
the attachment may be too big for a USENET post on some of the servers.

And yes, obviously I could go "full rogue" and use a binary chopper and
send it that way, and then a certain filter would open up with a
fifty caliber and none of my posts would go anywhere :-)

I would consider leaving posti... if the domain disappeared :-)

Paul

On Sat, 10 Feb 2024 21:21:54 -0500, Paul <nospam@needed.invalid> wrote:

>On 2/10/2024 8:41 PM, Char Jackson wrote:
>> On Sat, 10 Feb 2024 16:13:30 -0500, Paul <nospam@needed.invalid> wrote:
>>
>>> On 2/8/2024 10:03 PM, Andy Burns wrote:
>>>> Paul wrote:
>>>>
>>>>> https://i.postimg.cc/fknYTv9g/androidmic-startup.gif
>>>>
>>>> Ah, that's the second stretched image you've posted recently, the first time was the screenshot of disk manager you managed to extract as a binary attachment for someone, so I assumed it was an artefact of having to piece the image back together, and didn't mention it.
>>>>
>>>> But this one is a screenshot from your own system, it works ok if I click to zoom the image, but postimage is badly mangling the non-zoomed version ...
>>>
>>> Correct.
>>>
>>> In all cases, you must use your "craft" to get something
>>>from the exercise.
>>>
>>> Unfortunately.
>>>
>>> The other sites I might use, also present challenges,
>>> so it's not like any site is "righteous".
>>>
>>> "Download original image" is available as an option,
>>> no matter how they degrade the default image.
>>
>> If things get bad enough with the image hosting sites, we might have to go back
>> to how we did it for 30 years - by posting the image to Usenet, typically to a
>> garbage group such as alt.binaries.test, and including the MID in the text post.
>> I assume most, if not all, NNTP clients know how to open a MID. The downside is
>> that you lose the advertising that comes with the web-based sites.
>>
>
>Yes, on E-S there is a group for that purpose.
>
>However, depending on the size of the picture (I can do 10000 x 10000 on PostImage),
>the attachment may be too big for a USENET post on some of the servers.
>
>And yes, obviously I could go "full rogue" and use a binary chopper and
>send it that way, and then a certain filter would open up with a
>fifty caliber and none of my posts would go anywhere :-)
>
>I would consider leaving posti... if the domain disappeared :-)

I've never used E-S. It sounds awful. :-)
Just kidding, I'm sure it's fine in its own way.