search

Ylianst / MeshCentral

A complete web-based remote monitoring and management web site. Once setup you can install agents and perform remote desktop session to devices on the local network or over the Internet.
https://meshcentral.com
Apache License 2.0
4.25k stars 568 forks source link

XP Agent #2592

Open laboiteajb opened 3 years ago

laboiteajb commented 3 years ago

Hello,

I know that xp is not supported but I would like to restart the subject

We want to migrate from teamviewer to mesh, but we have clients in the medical world and they have software not compatible with other OS (or for budget reasons)

Is it not possible to create a lightweight agent for XP? (Which does not include all the functionality of the agent mesh for example)

Or a cmd agent that just allows RDP

do you have any solutions to get around this problem?

Thank you

Ylianst commented 3 years ago

A big problem with have with Windows XP is the difference in how we "fork" processes. No need to go into details, but we did look at it and it was a real pain to deal with. The light agent would be a possibility. I have a version of the agent that runs in NodeJS, maybe i could look at using that one.

laboiteajb commented 3 years ago

Hello,

do you have any news?

We had bad news from our side teamviewer 9 and 10 is no longer available from June 1

thank you

MailYouLater commented 3 years ago

Windows NT 5.x support would be awesome. I'd love to be able to install the MeshAgent on ReactOS based systems.

laboiteajb commented 3 years ago

Hello @Ylianst

do you have any news on the layout?

teamviewer just cut support for other old version again

thank you

si458 commented 1 year ago

@krayon007 does the agent support windows XP now at all? i tried running the agent 32bit exe but it just says its an invalid windows 32 bit application? we still have a SINGLE windows xp machine i would love to control remotely rather than RDP

krayon007 commented 1 year ago

There are a couple API's that we use when doing I/O that are not supported on Windows XP. The other issue, is that the executable format for XP is different, so even if we stripped out the components that weren't supported for XP, we'd still have this major issue to contend with, which screws up how code signing/authentication works.

si458 commented 1 year ago

we'd still have this major issue to contend with, which screws up how code signing/authentication works.

Do we really need to codesign the exes tho on windows xp?

I can understand 10/11/server etc, but xp?

EDIT: maybe a standalone exe just for xp? Strip out all the stuff that won't work with xp?

silversword411 commented 1 year ago

I'm quite certain XP is missing a ton of structural libraries modern remote access apps assume are there.

Can remove the checks...and I'm sure nothing will work. Then you're gonna want it to work...on a dying platform.

I think it's at the point of telling customers if you want support there will be a large, and ever increasing paid service fee if you want support for these old, unsupported systems. Pass on the true cost of legacy support and let them make the financial decision.

Next time, buy open source platforms. NASA is still running ancient redhat...and that's the price.of age.

silversword411 commented 1 year ago

You want support...$10k to maintain legacy 3 year contract...I'm sure at that point devs will be willing to make it work 😉

krayon007 commented 1 year ago

we'd still have this major issue to contend with, which screws up how code signing/authentication works.

Do we really need to codesign the exes tho on windows xp?

I can understand 10/11/server etc, but xp?

EDIT: maybe a standalone exe just for xp? Strip out all the stuff that won't work with xp?

For the code signing, it's done server side, so it would need to know if the windows client is XP or not. It is currently agnostic to the windows flavor.

On the client side, the agent parses it's own binary so it can fetch things like metadata, configuration, embedded scripts, etc. Because XP has a different PE format than windows 7 and newer, all that code won't work. I would need to rewrite it, not just rip it out, because the server embeds the msh configuration in the PE metadata. If I just rip it out, the agent won't have the configuration info.

MailYouLater commented 1 year ago

On the client side, the agent parses it's own binary so it can fetch things like metadata, configuration, embedded scripts, etc. Because XP has a different PE format than windows 7 and newer, all that code won't work. I would need to rewrite it, not just rip it out, because the server embeds the msh configuration in the PE metadata. If I just rip it out, the agent won't have the configuration info.

I'm not going to assume that's the only issue with WinXP support, but if that's what's holding you back from supporting NT 5.x, I think that placing a simple note in the docs and/or on the agent download page stating that Windows XP suport requires an appropriately named .msh file to be manually placed next to the agent's .exe file instead of rewriting that portion of code would be a perfectly acceptable compromise for those of us who want to use MC with Win XP machines.

And again, I'd also love to be able to use MeshCentral with my ReactOS test machines.