[Feature Request] Some ideas

[gjf]

Just some ideas to the whole design.

As for now we have two different folders for Win7 and Win10 with two different folders for x86 and x64 in each. Why don't you automate the process?

1. x32 and x64 vesrion of telegram.exe can be easily determined by parsing exe as text file. Check for the first occurence of "PE":
   • 32-bit (x86) programs would have PE L as the header.
   • 64-bit (x64) programs would have PE d† as the header.
2. Win version can be detected even easily - one can do it even in a simple batch file:

   @echo off
   setlocal
   for /f "tokens=4-5 delims=. " %%i in ('ver') do set VERSION=%%i.%%j
   if "%version%" == "10.0" echo Windows 10
   if "%version%" == "6.3" echo Windows 8.1
   if "%version%" == "6.2" echo Windows 8.
   if "%version%" == "6.1" echo Windows 7.
   if "%version%" == "6.0" echo Windows Vista.
   endlocal

3. Why put both dlls in strange TAR-Resources folder? You can use tzdata without any problem!
4. Why don't you create a loader with "telegram.exe" name that parses parameters and send them to child telegram.bin (that is original telegram) process? If so - this way will be very useful because you can substitute file on system without breaking associations.

In fact all these actions can be automated even in a script but I really think it would be better to put it in original project by design.

I'd be happy to help the author if any of my suggestions looked unclear.

Taking into account future advertisement "additions" in Telegram - I really think there is a big future in this project.

[SpriteOvO]

Good questions! Thanks! I will answer them in turn.

1. Yes, as you said, it is easy to determine the architecture of the target file, but getting the address of the API LoadLibraryW across architectures is much more complicated: first we need to parse the export table of the kernel32.dll file, get the offset of LoadLibraryW in the file, and then remotely get the address of kernel32.dll in memory. These tasks require writing hundreds of lines of code, but with the same architecture just one line of GetProcAddress(kernel32, "LoadLibraryW") will give us what we need. (In other words, I slacked off. :P)

2. Similarly, it is easy to determine the system version, but the problem is that version.dll export functions for Win7 and Win10 are a bit different. https://github.com/SpriteOvO/Telegram-Anti-Revoke/blob/de181c4bf43cfb24a8e29f022bc88d6b86703790/Source/Core/OS/Windows/DllMain.cpp#L13-L56 As you can see from the plugin's exported functions above, the indexes corresponding to the names of the exported functions no longer correspond from 3 onwards. Although most programs import functions by name rather than index, so even if the index is wrong it won't cause a problem, I just don't want to break the indexes.

3. tbh, I don't think it's strange.

4. If you update within Telegram, this will probably overwrite the plugin file and you will have to download the plugin again. If not, the associated path is also likely to change to itself after launch.

Finally, I don't intend to develop a feature to block ads, Telegram has already given too much as a free software, and I believe it will not show very annoying type of ads, which is acceptable to me.

[gjf]

Thanks for answers.

It looks like we are looking at this problem from different point of view. I don't suggest to change the code. I just suggest to create some kind of stub, a "starter" that will:

1. Check is telegram.exe presented in the same folder. If yes: 1A. Rename telegram.exe into telegram.bin 1B. Store/"remember" the information about telegram.exe bitness.
2. Check OS version.
3. Create a fake telegram.exe that will: 3A. Send all start parameters to real telegram.bin. 3B. Be specific to OS version (according to information from p2). 3C. Load dll corresponding to Telegram bitness (from p1B). 3D. Handle an update process and intercept it to store updated telegram.exe as telegram.bin

In fact p3D is not necessary as the user can simply start a stub once again after update.

Once I had a similar task in other world. Yes, the solution could be more pretty but I am a lazy bastard with strong batch scripting knowledge. So I coded it and then transfered to exe using some batch compiler:

if "%~1"=="u" goto uninstall
if "%~1"=="U" goto uninstall
if "%~1"=="/u" goto uninstall
if "%~1"=="/U" goto uninstall
if exist tspec32_orig.exe goto final
ren tspec32.exe tspec32_orig.exe
copy /b /v /y .\SysData\Languages\TSpec32ResourceCHS.dll .\SysData\Languages\TSpec32_origResourceCHS.dll
copy /b /v /y .\SysData\Languages\TSpec32ResourceDEU.dll .\SysData\Languages\TSpec32_origResourceDEU.dll
copy /b /v /y .\SysData\Languages\TSpec32ResourceENG.dll .\SysData\Languages\TSpec32_origResourceENG.dll
copy /b /v /y .\SysData\Languages\TSpec32ResourceESN.dll .\SysData\Languages\TSpec32_origResourceESN.dll
copy /b /v /y .\SysData\Languages\TSpec32ResourceFRA.dll .\SysData\Languages\TSpec32_origResourceFRA.dll
copy /b /v /y .\SysData\Languages\TSpec32ResourceJPN.dll .\SysData\Languages\TSpec32_origResourceJPN.dll
copy /b /v /y .\SysData\Languages\TSpec32ResourceRUS.dll .\SysData\Languages\TSpec32_origResourceRUS.dll
sc config MSSQL$ITEVA2014 start=demand
sc config MSSQL$ITEVA start=demand
sc config MSSQLFDLauncher$ITEVA2014 start=demand
sc config msftesql$ITEVA start=demand
sc config SQLBrowser start=demand
sc config SReportServer$ITEVA2014 start=demand
sc config SQLWriter start=demand

:final
move /Y %MYFILES%\starter.exe .\tspec32.exe
goto end

:uninstall
sc config MSSQL$ITEVA2014 start=auto
sc config MSSQL$ITEVA start=auto
sc config MSSQLFDLauncher$ITEVA2014 start=auto
sc config msftesql$ITEVA start=auto
rem sc config MSSQLServerADHelper start=disabled
rem sc config SQLAgent$ITEVA2014 start=disabled
sc config SQLBrowser start=demand
sc config SReportServer$ITEVA2014 start=demand
sc config SQLWriter start=demand
del .\tspec32.exe /q /f
rename .\tspec32_orig.exe tspec32.exe
del .\SysData\Languages\TSpec32_origResourceCHS.dll /q /f
del .\SysData\Languages\TSpec32_origResourceDEU.dll /q /f
del .\SysData\Languages\TSpec32_origResourceENG.dll /q /f
del .\SysData\Languages\TSpec32_origResourceESN.dll /q /f
del .\SysData\Languages\TSpec32_origResourceFRA.dll /q /f
del .\SysData\Languages\TSpec32_origResourceJPN.dll /q /f
del .\SysData\Languages\TSpec32_origResourceRUS.dll /q /f

:end
del %~s0 /q /f

Whereas "starter.exe" in fact is:

sc start MSSQL$ITEVA2014
sc start MSSQL$ITEVA
ping -n 3 127.0.0.1 > nul
start /wait tspec32_orig.exe
sc stop MSSQL$ITEVA2014
sc stop MSSQL$ITEVA
sc stop MSSQLFDLauncher$ITEVA2014
sc stop msftesql$ITEVA
sc stop MSSQLServerADHelper
sc stop SQLAgent$ITEVA2014
sc stop SQLBrowser
sc stop SReportServer$ITEVA2014
sc stop SQLWriter
del %~s0 /q /f

This code was of course simpler then I requested and in fact just allows to start and stop MSSQL only when it is required. However I don't think it will require too much work to create a starter for your modules as well as add parameter transfer from "TAR-Launcher-XXX.exe" (renamed to telegram.exe) to telegram.exe (renamed to telegram.bin).

[iamb9]

Kindly add a Cool Icon to TAR-Launcher-ARCH.exe. Thanks