Custom Query (301 matches)

On OS/2 QMLViewer should output it's help message in a window instead of sending it to the console.

Initial trials with using highmem -c on all Qt-DLLs look promising. It saves quite some low shared mem and as such makes the system run more stable because running out of low shared mem is the nr. 1 reasons for system crashes here.

A possible crash was however observed, wenn I closed SMPlayer with psi 0.15 also running. psi immediately crashed in MMPM.DLL

Killed by SIGSEGV
pid=0x0078 ppid=0x0026 tid=0x0001 slot=0x00d4 pri=0x0200 mc=0x0001
D:\PROGRAMS\PSI015\PSI.EXE
MMPM 0:00060561
cs:eip=005b:1e620561      ss:esp=0053:00efdc5c      ebp=00efdca8
 ds=0053      es=0053      fs=150b      gs=0000     efl=00000206
eax=00000002 ebx=189e002c ecx=00000009 edx=18d70158 edi=18d20770 esi=189e002c
Process dumping was disabled, use DUMPPROC / PROCDUMP to enable it.

Currently, Qt binaries (in particular, qmake.exe and QtCore4*.dll) have hard-coded paths in them that refer to various locations (e.g. include directory or plugin directory). This makes it impossible to distribute the Qt library in the binary form (for example, in order to provide a fast-to-deploy development environment that uses the officially distributed Qt libraries, tools and DLLs which makes it possible to distribute Qt DLLs separately from each Qt application and at the same time avoid DLL hell).

In particular, qmake uses these hard-coded paths when generating the Makefiles so if the Qt library root is changed (moved, renamed) an attempt to build an application will fail because include and library files will still be searched at the old location (whose path is built into qmake.exe).

In case of QtCore4.dll and its hard-coded paths, the potential problem is locating the Qt plugins that are by default searched at the hard-coded location that points inside the 'plugins' subdirectory of the Qt library root.