tMorph World of Warcraft MoP 5.4.8 / Legion 7.1.5

[Arikania]

I play World of Warcraft on a server that allows the use of tMorph, an injector that can be used to look more fashionable on one's own client.

First, tMorph worked fine with Wine, but after upgrading Wine, tMorph won't connect to my WoW client anymore. Upon reverting to the older Wine, it still wouldn't work anymore. Occasionally, like 1 in 15 times, Wow will kick in with tMorph working. Now I run Wine 2.0.4 stable.

Whatever I try, tMorph won't see my Wow-64.exe anymore, even though it does show up in top as it should.


Also, I can't get the Legion 7.1.5 launcher working on another server.


CPU: 4x Intel i5 (64 bits) Cores
OS: Linux Mint 18.2 Sonya, Cinnamon 3.4.6
Graphics: NVIDIA GM107 [GeForce GTX 745]
Memory: 8 GB

[steveebey73742]

playing wow on private server is against blizzard tos and you likely will get no help here.

[Arikania]

It is indeed against the Blizzard ToS, but that is not the server where I play.

I play on a server where the use of tMorph is allowed.

And even if Blizzard would condone tMorph or similar programs, I doubt they would bother to offer actual assistence for external programs.


Kindly,

[Cybermax]

playing wow on private server is against blizzard tos and you likely will get no help here.

"No help here" what?

Are you the "Blizzard Police"?

A more honest answer would be "I have never played WoW with tMorph, so have no clue.. Post logs of xxxx.log"... ofc still would not help anything, but atleast someone would pretend to help

And the little help i CAN offer is: WoW or Overwatch (possibly other blizzard games), AND battle.net client, does not work with "release" version of Wine. You need "Staging" to be able to run WoW atleast on an official server. Have no clue how those private servers do the authentication tho

[Arikania]

No, I am definitely not Blizzard Police lol. I don't even play there.

WoW MoP 5.4.8 (which I start without a launcher) works fine with Wine 2,0.4 stable, which I am using. Freakz WoW (which does use a launcher) is an issue yet though. I will look into the staging version yet.

Launchers are a well-known bottleneck for Wine.

I suspect that that is because, if a .exe under Wine starts another program, Wine somehow attempts to start a Linux program, not another Windows program.

I do have an update on the tMorph issue though: it has to do with a memory leak.

I am aware that tMorph itself has one, but Wine does not clean up that memory either. Because if I ran WoW + tMorph, and I restart my computer, then WoW will start with tMorph hooking in correctly.

Something that the Wine dev team should look into perhaps?

My MoP issue would pretty much resolved if I knew how I could restart the wineserver daemon. i.e. shut it down an restart it. I tried sudo service winbind restart but that didn't do the trick.


With regards,

[Bob Wya]

I suspect that that is because, if a .exe under Wine starts another program, Wine somehow attempts to start a Linux program, not another Windows program.

Que?

@Arikania

See:

Code: Select all

man wineserver

You can kill all the Wine processes running in a WINEPREFIX with:

Code: Select all

wineserver -k

You can restart the wineserver process directly.
Or (more typically) by running any application in the WINEPREFIX - using Wine. This will indirectly start the wineserver process again.

Bob

[Arikania]

Ah great! Big thanks Bob!

One misconception though, although it may be a matter of configuration. But on my computer, when the wineserver started, it keeps running, and does not restart when I launch the previously run program again. This is indicated by the fact that WoW behaves differently when started for the first time and for the next times.

Thus it appears that I need to kill the wineserver explicitly.

I tried it now, but wineserver -k and env WINEPREFIX=myWoWprefix wineserver -k do not work. I don't even get notified that something actually happened!

[Bob Wya]

@Arikania

Is the wineserver you calling from the same package as the wine executable? A bit of a long shot... ??!!

What's the output from:

Code: Select all

readlink -f $(which wineserver wine)

Also make sure you're doing the WINEPREFIX handling right...
Lots of people screw this up early on (including me!)

If your testing in a terminal it's generally safer to do:

Code: Select all

export WINEPREFIX=' ... '
...
wine WOW.exe

Then the WINEPREFIX environment variable will persist in that terminal session only.
But if you start another terminal session you would have to export the WINEPREFIX variable again.

It's easy to forget, or inadvertently not set, the WINEPREFIX variable and Wine will refer straight back to the default WINEPREFIX of:

Code: Select all

~/.wine

Double check your current session settings with:

Code: Select all

env | grep WINE

There are some rare instances of:

Code: Select all

wineserver -k

leaving behind rogue processes - but in my experience this command usually nukes the lot!

Bob

[dimesio]

I tried it now, but wineserver -k and env WINEPREFIX=myWoWprefix wineserver -k do not work. I don't even get notified that something actually happened! :(

Try

Code: Select all

killall wineserver

You should also check for other processes left still running; you may have to kill those, too. Unlike Bob, my experience is that it's not rare.

[Arikania]

@Bob Wya

In my /etc/bash.basrc I have:

Code: Select all

export WINEARCH=win64
export WINEPREFIX="/home/$USER/h/wine64"

The readlink command yields:

Code: Select all

/opt/wine-stable/bin/wineserver
/opt/wine-stable/bin/wine

The grep command gives:

Code: Select all

WINEARCH=win64
WINEPREFIX=/home/alicia/h/wine64

You will notice that I'm using the stable version, while the staging version is recommended for WoW. But it is when I upgraded to the staging version that my problems began. So I re-installed the stable version again, hoping that it would revert the issue. Tough luck!


@Moderator
The command killall wineserver did something peculiar!

My test run came up with this:

1. Starting WoW + tMorph --> tMorph failed
2. killall wineserver --> reply: "no process found"
3. Starting WoW + tMorph --> tMorph succeeded

and all next times, step 2 came with the very same reply, but tMorph failed again. Perhaps I need to send any specific signal when I use killall? My account is an Administrator account, so I am able to run commands with more elaborate consequences.


I'm grateful to both of you btw for your time and patience.


Kindly
Arikania

[Bob Wya]

...
My test run came up with this:

1. Starting WoW + tMorph --> tMorph failed
...
3. Starting WoW + tMorph --> tMorph succeeded
...

@Arikania

• How are you actually starting these processes?
• Manually from a terminal? If not you should be when testing Wine issues!
• If so - what commands are you using exactly?

That's actually quite crucial information - especially if you're relying on /etc/bash.basrc to set your environment globally.

Bob

[Arikania]

Although I usually start it with the .desktop file in my menu, which in turn starts the script, listed below. This script is in my path, so I can start it from the terminal as well, which I did while testing it:

Code: Select all

#! /bin/bash

## wmop [options]	17.03.19a

## Options:
#  --kill		Removes Wow-64.exe from the running processes
#  --tmorph		Injects tMorph


hError()		{ echo -e "$mHead $@" >> /dev/stderr; exit 1; }


Wine()
{ env WINEARCH=win64 WINEPREFIX="$Prefix" WINEDEBUG=-all wine "$1" & return; }


mHead="$(basename "$0"):"
Prefix="/home/$USER/h/wine64"
tMorph=""
Uniques=""
WinDir="/myWinDir"
WoW="Wow-64.exe"


while [ -n "$1" ]; do
  WoWFail=$Uniques

  case "$1" in
    --kill)
      [ -n "$tMorph" ] && WoWFail="X"
      Uniques=$1
    ;;


    --tmorph)
      [ -n "$tMorph" ] && WoWFail="X"
      tMorph="X"
    ;;


    *)
      hError "Unknown argument \e[4m$1\e[0m"
    ;;
  esac


  [ -n "$WoWFail" ] && hError "Improper use of \e[4m$1\e[0m"
  shift
done


if [ "$Uniques" == "--kill" ]; then
  [ -z `pidof $WoW` ] && hError "WoW is not running"

  killall -q $WoW
  sleep 1

  [ -n "$?" -a "$?" != "0" ] && hError "Unable to stop WoW; it is owned by another user"
  [ -z `pidof $WoW` ] || hError "Not all instances of WoW could be stopped"

  echo "$mHead WoW is stopped"
  exit
fi


[ -d "$Prefix" ] || \
  { WowFail="X"; hError "The wine prefix \e[4m$Prefix\e[0m does not exist"; }

[ $UID == 0 ]	 && { WowFail="X"; hError "WoW cannot not be started as root"; }
[ $XAUTHORITY ]	 || { WowFail="X"; hError "WoW cannot be started from TTY"; }

[ -n "$WowFail" ] && exit 1


Wine "$WinDir/my_wow_dir/$WoW" & [ -n "$tMorph" ] && {
  while [ -z "`pidof $WoW`" ]; do
    sleep 1
  done

  sleep 7


  cd "$WinDir/my_tmorph_dir"
  echo | Wine "./tInject.exe" >> /dev/null
}

[Cybermax]

Is "tmorph" a 64 bit or 32 bit program?

There is sometimes troubles with launchers if you switch between 32 <-> 64 bit programs.. like Battle.net launcher starting wow-64.exe, as Battle.net app is a 32-bit program. And it also seem as wow-64.exe starts "agent.exe" which does not always close in a timely/normal fashion, keeping wineserver alive.

I found that out after doing some tests by using the "virtual desktop" function of wine, and upon closing the app, the desktop would not close until i kill agent.exe...

To prevent agent.exe from launching, you can build your own "pure" 64 bit wine, but be aware that ONLY 64 bit windows .exe files will run (like wow-64.exe, but possibly not that tmorph thing).

Also try to experiment with the "virtual desktop" feature of wine.. easy to actually verify that all wine apps are closed properly cos if the apps started under that wineserver instance is not "dead", then the desktop will stay up

[Arikania]

tMorph is 64-bit exclusively. That is the very reason that I use Wow-64.exe instead of Wow.exe.

The WoW that I use tMorph with (Mists of Pandaria 5.4.8 ) is started without the launcher.

I didn't use the virtual desktop often, but the times that I did, it shut down when my WoW did. wineserver does not show up in my top menu anymore after I closed WoW.

What is agent.exe? It does not ring any bell with me... Okay, I checked the BattleNet forum now. agent.exe does not show up in my top at any time. The BN forum suggests that it is started by the launcher, which I don't use.

Does wine have an agent.exe as well then?

I will look into the virtual desktop thing further, although it's strange that I never needed it before.


Thanks for replying to my post I really appreciate it!

[Cybermax]

Does wine have an agent.exe as well then?

No, Agent.exe is a blizzard app... but i recently found out that if i start wow-64.exe with a wine version build for 32/64 bit, agent.exe will launch a short while in the background even tho its supposedly only able to do that when started from the battle.net launcher.

Agent.exe i THINK is responsible for background downloading. It might also be that this new "feature" only came about around 7.3 and Legion tho.

So.. how do i KNOW that agent.exe is trying to start even tho i just start wow-64.exe you say?
Snippit from my latest gaming session:

Code: Select all

[01/13/18 19:59:09] - Running wine-staging-2.18 Wow-64.exe -d3d11 (Working directory : /home/xxxxxxx/.PlayOnLinux/wineprefix/Battle.net/drive_c/Program Files (x86)/World of Warcraft)
wine: Bad EXE format for C:\users\Public\Application Data\Battle.net\Agent\Agent.exe.
wine: Bad EXE format for C:\users\Public\Application Data\Battle.net\Agent\Agent.exe.
wine: Bad EXE format for C:\users\Public\Application Data\Battle.net\Agent\Agent.exe.
wine: Bad EXE format for C:\users\Public\Application Data\Battle.net\Agent\Agent.exe.
wine: Bad EXE format for C:\users\Public\Application Data\Battle.net\Agent\Agent.exe.

I use PlayOnLinux as my wine launcher, as its easy to switch prefixes and wine versions.

Reason for "Bad EXE format" is cos i compiled wine with --enable-win64 only, thus creating a 64-bit only wine that dont run any 32-bit programs. (Purely because of this agent.exe crap)

[Arikania]

Wine HQ, please solve the memory leak that you introduced somewhere between 1.8 and 2.0.4! I get tired of having to restart my computer over and over again because Wine does not clean up its memory after shutting down a program, which it did right in 1.8, but not the in 2.0.4 stable that i use now. It puts a strain on my data carriers as well.


Kindly,

Arikania

[Arikania]

The memory mentioned in the post hereaboe is not even released upon logout, so it seems that Wine is creating memory with suspicious credentials. Al memory created should be owned by the Wine user, to prevent enabling unauthorized actions, imo.