QuArK

Run with:
LC_ALL=chinese wine QuArK.exe

LC_ALL=greek wine QuArK.exe works better, otherwise you i'm not able to read the file dialogs :)

The solution to solve this bug is simple, you have to replace the data with single quote by a double quote into the file :

setup.qrk :
Building:config =

{

AutoSave = "20"

}

default.qrk : for all the values
Building:config =

{

DefPoly = "128x128x128"

WallWidth = "-8"

mpOffset = "0 0 64"

mpZoom = "2"

mpRotate = "15"

ForceAngleStep = "15"

AutoSave = "10"

AutoSaveRun = "1"

LinearWarning = "1"

//BezierCenterX = "-32"

//BezierCenterY = "-32"

Form = "MapBuilding"

}

But the issue is that each time that you save your configuration (map/building => autosave ). The value of autosave in setup.qrk is set to '20' and when you restart quark you will have the same issue because of single quote.

Also if you want to solve definitevely this issue you can update the file mapeditor.py like that :

def autosavetime():
#minutes = int(quarkx.setupsubset(SS_MAP, "Building")["AutoSave"])
#return minutes * 60000
return 10 * 60000

It is not very elegant but it efficient => wine quark.exe (create new map) WORKS !


This means also that winehq don't handle the quote and double quote as windows do it .... But I don't know how to solve it ...


hereafter a Python print of the value received with single quote :

SS_MAP ForceAngleStep= (15.0,)
SS_MAP AutoSave= A
SS_MAP AutoSaveRun= 1


hereafter a Python print of the value received with double quote :

SS_MAP ForceAngleStep= 15
SS_MAP AutoSave= 10
SS_MAP AutoSaveRun= 1


this the original code where the erros occurs :
def autosavetime():
minutes = int(quarkx.setupsubset(SS_MAP, "Building")["AutoSave"])
return minutes * 60000


We try to find a solution with cdundee. I will inform you if we find a solution.

We have investiagte more with cdundee but no solution

-if we use double quote on unix the windows application crash ( delphi is used)

-if we use single quote wine/quark on linux crash.

any idea how to solve the wine issue ?

Some time ago I figured out what was happening, and the issue has since been fixed (it's in the "SpecificsFix"-patch for QuArK 6.6.0 Beta 6). I'll document it here.

QuArK internally stores data as key-value pairs, supporting values types of String or (an array of) floats. To distinguish between the two, QuArK abuses the first character of the key-string: if its high-bit is set, it's (an array of) floats, otherwise it's a String. Because all known key-names are lower-table ASCII, and because empty key-names don't happen in real life, this works out just fine, and doesn't require the implementation of a Delphi TList-class that supports multiple data types. When outputting to a file, it strips the high-bit, and the choice of quotes are used to signal the type: double-quotes for Strings, single-quotes for (an array of) floats. The proposed "fix" is thus incorrect: it may work as a workaround, but only because floats are now stored as strings.

The actual problem is due to a bug in Delphi itself. Delphi supports several types of String encoding, including MBCS, and switches between them based on locale. However, there is an incorrect function call in the IndexOfName-function of TStrings, leading to String-type-confusion for the key-names. Because of that and the way QuArK searches the key-value pairs (first try with the high-bit set, if not found, try without it), key-names that don't matched are being treated as equal, and thus value data types are being mixed, leading to errors (trying to interpret Stings as floats).

On most English Windows', the locale causes Delphi not to run this broken code-path, and thus it doesn't exhibit this bug. However, it's known to occur on, for example, Chinese Windows XP. Due to slight differences in locale-handling between Windows and Wine, Wine in Windows XP compatibility mode does trigger the bug, even if the language is set to English.

The published patch wraps the broken IndexOfName-function, and if a match is returned by it, it performs a CompareMem (binary compare) to make sure the returned item's name really matches, including the high-bit on the first character. This prevents the value data type confusion, and thus corrects the issue both on Windows and under Wine.