Closed casper closed 2 years ago
@casper I'm afraid, backporting those changes will be hard to do. As well as reproducing the old build environment, used to build the old versions.
Building a modern version for old systems may be possible in case of Windows XP, although it requires a lot of work. I think it'll be very hard for OS X before 10.9 and I'm not sure if it is possible for Linux 32 bit.
Thanks @john-preston. This was the commit I found. Is this all of it, or do you know if there are more changes involved than this one?
Many people still us old hardware, unable to update to newer operating systems. Version 1.8.15 has been working perfectly on these older machines for many years. Now a single update to 64-bit IDs will render all these machines unable to use Telegram :(
on my city you can buy 64 bits 2nd hand computer with windows 10 for 50 euro.... unless your computer is very very old (> 16 years old) go install some modern linux on it. (ie ZorinOS)
@casper This commit isn't relevant to 64 bits, sorry. The required ones were before.
The problem is, the server detects the support only by the app using the new API, that supports 64 bit ids. So the only way to make it work is to build the new app (which supports the new API) with the old target system.
The problem is that the modern code relies on the new version of dependencies, libraries, that dropped the old systems support as well. So it is a complex process.
Also the new toolchain may not support targeting old systems at all, this is the case with OS X 10.8 and below. And the old toolchain may not support the new C++ language features, that are used across the modern code base.
Might I ask why you can't use newer versions of Telegram?
on my city you can buy 64 bits 2nd hand computer with windows 10 for 50 euro....
yay e-waste
Doing the backport myself? Is it possible? Is the update to files in the
data
folder all that is required?
If you would be able to run Qt 5.15 on Windows XP, you would be able to run tdesktop. Maybe there are some patches for Qt in the internet. Or you can try to install something like One-Core-API.
@ilya-fedin There may be some problem with ffmpeg as well.
There may be some problem with ffmpeg as well.
does ffmpeg use any winapi (in the parts needed for tdesktop, i.e. codecs)?
@ilya-fedin Yes, it does. As far as I remember 2.4 did support XP, while 4.* already doesn’t. But maybe I’m wrong.
If you would be able to run Qt 5.15 on Windows XP, you would be able to run tdesktop.
I think there is no support for Qt on XP for that version(?) It would be very hard to get Qt 5.15 to work on XP, right? That's why I was thinking maybe it would be easier to just patch 1.8.15 for the new protocol. No need to support new GUI features, just as long as it can talk with the server.
There is one other project called Extended Kernel, which brings Win 7 kernel calls to older OS versions, but it is still in experimental stage. The missing calls is the reason Qt does not run. Ffmpeg also has this problem, although I think I have seen backport patches for that one for both XP and Vista.
It would be very hard to get Qt 5.15 to work on XP, right?
I don't know, maybe there are patches on the internet. Backporting Qt 5.15/6.2 to macOS 10.12 wasn't require big changes, for instance, just a few if-s for the new API.
duplicate of .. issue #17330 closed by @Aokromes and hijaked by a person like @ilya-fedin just take the issue as a jocke..
@casper I'm afraid, backporting those changes will be hard to do. As well as reproducing the old build environment, used to build the old versions.
Building a modern version for old systems may be possible in case of Windows XP, although it requires a lot of work. I think it'll be very hard for OS X before 10.9 and I'm not sure if it is possible for Linux 32 bit.
i guess debian mantainers do packages for 32bit linuxed.. but not so up to date.. what about work in team with debian mantainers.. or feladora rpm fusion team?
currently we canot request lot of people changed lot of gigs of program already configured just removed and changed to 64bit if there's already working OS.. just by one program..
NOTE: in 2038 all 32bit will be gone due the limit in dates from bios!
@mckaygerhard the reason of your issue was to require a build, the reason of this issue is to discuss alternatives including self-building.
btw, about alternatives, there are web clients
Thanks @john-preston. This was the commit I found. Is this all of it, or do you know if there are more changes involved than this one?
1e660fc#diff-068fb29de5aea20f0cb99126df8a348de39fe8097b8f1d1420ac64ede5320e50
yeah @ilya-fedin but two things: first one you just arges to "buy" .. to users.. not so kind of response.. and second.. backporting this commit in my little knowledge of compilers only results in some warnings.. also setup older environment is not so hard.. by example a container with debian archives repos is available.. and possible..
unfortunately i do not have enough skills to do the job.. and i also busy made backports of minetest for older mobiles.. you developers always thinking people likes "fashion edge of tech" and there's no care about.. users just want to use their stuff without hastias updates..
it seems that there's possibility to made the backport, just we need more collaboration.. but no more "buy new device" responses, those kind of responses makes people likes closed source solutions:
IMPORTANT minetest developers they discarded all users who had old phones, and now 99% run clients derived from the old versions. so please take in consideration that Telegram is widely used cos is also working in older devices (phones or computers.. ) contrary of the whatups crap
first one you just arges to "buy" .. to users..
I never said you should buy something, all I said supporting hardware from 2002 doesn't worth the effort. The word 'buy' can be found in your messages only. How to solve the problem of unavailable software is your something you should decide yourself.
and second.. backporting this commit in my little knowledge of compilers only results in some warnings..
Which commit? I never talked about backporting commits.
but no more "buy new device" responses
Show me where I said "buy new device".
@john-preston @casper i am looking for commit and i gues was the https://github.com/telegramdesktop/tdesktop/commit/a6c98f4bb44c8a5f55f86ea80f932a5d0a8be1e3 as i know in my knowledge..
@casper versions 1.8.15 on OS X 10.6, 10.7, 10.8, 10.9, Windows XP, Windows Vista and 2.4.4 on OS X 10.10, 10.11 and 32 bit Linux systems should allow you to log in (using another already logged in Telegram session) and use it except for chatting with newly registered users. They were allowed from the server side, but to be able to chat with all users you still need a new version on a (relatively) modern OS (Windows 7+, macOS 10.12+, Linux x86_64).
@john-preston Oh ok. Well that helps a little bit that is just doesn't stop working completely. Thank you.
Another thing I was still trying to think of different solutions besides full backporting. Something simpler which would allow 64-bit UID with minimal changes.
My question is, wouldn't it be possible for the 1.8.15 API to just start transmitting 64 bit UIDs instead? Then there would be minimal work required on the 1.8.15 client, compared to all the other solutions. No API backport required.
This is the simplest change I could think of, which requires the minimum amount of code change in total. What do you think of something like that?
I'm sure a change like that could be implemented by volunteers on the 1.8.15 code base, if the server just started sending the 64 bit UIDs(?) Call the new API something like API 1.8.15 v64bit. Is this possible, or am I simplifying too much?
@casper Yes, I'm afraid this is not going to work :( the Telegram API has a linear way of improving, each layer adds complexity. And nobody will add and support a special layer based on some older one with huge amount of changes.
now all my phones can able to send media! puff i knowalcatel touch pixie is pretty older but is working.. my real hit is my linux 32bit devices..
i try to login using the scancode but scan code does not appears in the older client.. now.. yesteday is happened but today's was cut off
i check other project that already implemented the change with no new features.. (if we just follow the slow development of) as tdlib by exampĺe
or feladora rpm fusion team?
Fedora dropped the x86-32 architecture two years ago and will drop 32-bit ARM next year.
I'm sure a change like that could be implemented by volunteers on the 1.8.15 code base, if the server just started sending the 64 bit UIDs(?) Call the new API something like API 1.8.15 v64bit. Is this possible, or am I simplifying too much?
this is a man-in-the middle way.. but not possible due nature of the telegram api, so i put the commit a6c98f4 few commends ago related to the change, maybe we need to trush in projects like tdlib that already backported the change!
@john-preston Oh ok. Well that helps a little bit that is just doesn't stop working completely. Thank you.
it does not work anymore .. i tested today
it does not work anymore .. i tested today
@mckaygerhard I am using 1.8.15 right now on WIndows Vista. I have my original session since many months ago. Never logged out. It seems to work as long as you have the session credentials (tdata
folder). Perhaps it's possible to copy the tdata
folder from another client to get a valid session. Not sure, but might be worth a try.
@mckaygerhard Tdlib didn't backport anything. It supports the latest API layer, the same tdesktop 3.2.5 supports. With all the features added in the last years.
it does not work anymore .. i tested today
@mckaygerhard I am using 1.8.15 right now on WIndows Vista. I have my original session since many months ago. Never logged out. It seems to work as long as you have the session credentials (
tdata
folder).
yes that's true but cannot receive new chats as mentioned.. i m able to send messages but sudeently a hole screen cover all and said to upgrade.. i do not open anymore.. also i am not using windo crap but i will try to test with older data to check if works 1.8 (it seems 2.X does not work)
Perhaps it's possible to copy the
tdata
folder from another client to get a valid session. Not sure, but might be worth a try.
i will try that .. and report feedback here
i does not work, maybe the data directory must be equal. but the login process that @john-preston describes does not work .. with my other already loge client (was working the day of the mess with scancode.. but now is not more )
for windows xp users, i suggest yo use maxthon browser and telegram web.
i want 32bit builds liek the windo does.. as equality
我先看看吧
---Original--- From: @.> Date: Fri, Dec 10, 2021 00:45 AM To: @.>; Cc: @.***>; Subject: Re: [telegramdesktop/tdesktop] Possible to backport 64-bit useridentifiers to 1.8.15? (Issue #17330)
i want 32bit builds liek the windo does.. as equality
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or unsubscribe.
linux 32bit builds now! with centos 6 and debian 8 compatibility also
you can find them in TARDIS
是
---Original--- From: "Герхард PICCORO Lenz @.> Date: Fri, Dec 10, 2021 20:10 PM To: @.>; Cc: @.**@.>; Subject: Re: [telegramdesktop/tdesktop] Possible to backport 64-bit useridentifiers to 1.8.15? (Issue #17330)
linux 32bit builds now! with centos 6 and debian 8 compatibility also
— You are receiving this because you commented. Reply to this email directly, view it on GitHub, or unsubscribe.
hi @GUOguocai88 is better to write in english.. so they can pretty understadn is not only me that wants 32bit builds
謝謝你的提醒,因為我的電腦被收了,所以我只能用手機給你們發消息。
---Original--- From: "Герхард PICCORO Lenz @.> Date: Fri, Dec 10, 2021 20:16 PM To: @.>; Cc: @.**@.>; Subject: Re: [telegramdesktop/tdesktop] Possible to backport 64-bit useridentifiers to 1.8.15? (Issue #17330)
hi @GUOguocai88 is better to write in english.. so they can pretty understadn is not only me that wants 32bit builds
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or unsubscribe.
謝謝你的提醒,因為我的電腦被收了,所以我只能用手機給你們發消息。
err but .. google translator was also loading in the phone in my case.. so ..
Hey there!
This issue was inactive for a long time and will be automatically closed in 30 days if there isn't any further activity. We therefore assume that the user has lost interest or resolved the problem on their own.
Don't worry though; if this is an error, let us know with a comment and we'll be happy to reopen the issue.
Thanks!
this issue still is present.. there are users that only uses 32bit..
The answer has been given, so literally the issue could be closed
The answer has been given, so literally the issue could be closed
that is a workaround not the solution.. noted that the older pidgin plugin can log in but that plugin its just a test project..
There won't be official 32-bit builds, that's the decision that was told multiple times and there's no sense in this issue being open. Move on.
There won't be official 32-bit builds, that's the decision that was told multiple times and there's no sense in this issue being open. Move on.
that is a dictatorship and unfair dessition.. there's 32bit builds for windosers but not for linux users .. a irony cos the build system is over linux.. and windos users that download the 32bit version does not contribute here in any way, GREAT!
a irony cos the build system is over linux
That's some bullshit, the build system is primary WIndows-oriented as well as the entire project is.
and windos users that download the 32bit version does not contribute here in any way, GREAT!
You say like linux users do. tdesktop community rarely contributes something, most of the community can only ask and never gives. If you look at all contributes except of preston's, 23rd's and mine, you will see only minor commits to fix build from package maintainers.
There are some linux-specific feature requests where it's been told that it won't be done by me or preston and the willing people can do it on their own & PR. Guess what? No one stepped up.
There won't be official 32-bit builds, that's the decision that was told multiple times and there's no sense in this issue being open. Move on.
that is a dictatorship and unfair dessition.. there's 32bit builds for windosers but not for linux users .. a irony cos the build system is over linux.. and windos users that download the 32bit version does not contribute here in any way, GREAT!
there is no reason to stuck on 32 bits os, on my country you can buy second hand 64 bits capable computer for 40 euro.
that is a dictatorship and unfair dessition.. there's 32bit builds for windosers but not for linux users .. a irony cos the build system is over linux.. and windos users that download the 32bit version does not contribute here in any way, GREAT!
there is no reason to stuck on 32 bits os, on my country you can buy second hand 64 bits capable computer for 40 euro.
in LATAM 40 E is a full month of salary.. such europeans always making metric based only in their little world
I wonder what would you do if tdeskop provided no official builds (only the sources) for Linux as most Linux software do
I wonder what would you do if tdeskop provided no official builds (only the sources) for Linux as most Linux software do
in such cases. the telgram network will decrease users.. cos if you noted.. windosers liked more what'sup.. your builds for windos are made over linux adapted environments..
i recommended to you to do that! lest see the results @ilya-fedin .. made the challenge
there is no reason to stuck on 32 bits os, on my country you can buy second hand 64 bits capable computer for 40 euro.
Thanks to everyone that replied here. I just wanted to comment that if 40 euros was all it took to solve this problem (in my case), I would never have opened an issue in the first place.
I wish it were, but it is not.
For me personally it is a handicap problem that is too complex and too personal to go into on Github. But this prevents me from upgrading this computer, which is the only one I am able to use. I cannot upgrade the OS, nor can I upgrade the hardware.
I imagine there could be a few people in a similar situation as me, or perhaps because of other, maybe financial reasons too, cannot upgrade.
I usually do not like to go around explaining this, but I just wanted to point out that reasons for requests like this may not always be as simple as people initially assume.
I am just thankful I am still able to run the 32-bit version. It works, although not fully, but enough to be usable for now. Thanks to everyone that contributes.
your builds for windos are made over linux adapted environments..
I don't quite understand what do you mean, but Windows builds are fully native and are built with Visual Studio. Linux has nothing to do with Windows builds.
the telgram network will decrease users..
Well, Linux is only 2% of the userbase now and 32-bit Linux was 1.2% at the time of drop.
Is your feature request related to a problem?
Telegram is switching to 64-bit user identifiers, making all the old 1.8.15 clients obsolete.
Describe the solution you'd like
Many people still us old hardware, unable to update to newer operating systems. Version 1.8.15 has been working perfectly on these older machines for many years. Now a single update to 64-bit IDs will render all these machines unable to use Telegram :(
I was looking at the commit for the 64-bit UID change, and the change looks to be isolated to only a few files in the
data
folder. Wouldn't this make a backport feasible for 1.8.15, since the 64-bit update to the code looks very contained?If it is contained, perhaps a backport would be possible? Something all the 1.8.15 users would be very grateful for.
Thank you. And thank you for such a great program.
Describe alternatives you've considered
Doing the backport myself? Is it possible? Is the update to files in the
data
folder all that is required?Additional context
No response