| Trolltech Home | Qt-interest Home | Recent Threads | All Threads | Author | Date | |
| All threads index page 1 | |
RZ schrieb:
>>
>>> Totally off-topic for this group but concerning Vista (and also
>>> deployment):
>>> the 'Feature' of translating directory names:
>>> c:\program files in a german windows explorer get's translated to
>>> c:\programme
>>
>> Again this is not specific to Vista. In fact this has been the case
>> since Windows 95 I believe (where have you been the last 10 years?
>> ...
> i don't think we talk about the same here.
> as you can see in the attached part of a screenshot i now got two
> (physically not identical!) folders given the same name.
> (one who's really named c:\programme and one who's translated to
> c:\programme).
Uh oh... where have *I* been when Vista came out? Obviously (and
luckily) far away, as it seems :)
No, I certainly would have never expected to find two folders apparently
named exactly the same and I certainly did not ever observe this on any
Windows up to and including Windows XP.
What I observed was that certain programs (and I'm not sure, but even
some utility programs from Microsoft themselves!) really just install
under c:\Program Files instead of c:\Programme on my german Windows XP.
The same trouble goes for "My Settings" etc.
But your observation certainly beats that ;)
By the way I have attached a "build framework" - in your case it is
probably way too late since you have already figured out a solution, but
still you might be interested how I setup a project, deploy the DLLs, Qt
plugins, manifests etc.
The "AppFramework" offers two deployments (on Windows):
* a simple Visual Studio 2005 Setup project which also distributes the
vcredist_x86.exe together with all the Qt (4.3.1) DLLs and (image)
plugins, the i18n files. It also registers the "lib" subdirectory to
be in the PATH when the *.exe is started
* a simple bin directory which contains everything needed for running
the app on a naked target system (1), with a private assembly of
the C++ runtime libs, as described in the MSDN docs.
Building the app is simple:
Windows: Load the solution *.sln file and hit F7 (Build Solution)
Unix: cd into the AppFramework directory and type "gmake dist", which
will result in the binaries etc. being in the
"bin/linux-g++_release" folder, for example
(you need 'gmake':
on Ubuntu Linux 'gmake' is simply called 'make', so either edit
the GNUmakefiles or do a symbolic link from 'gmake' to 'make'
in /usr/bin)
It also has a nice Unix build framework based on a "GNUmakefile wrapper"
(which basically does nothing more than generating the qmake based files
with a unique name, given the QMAKESPEC, so that you can run
simultaneous build runs in the /same/ directory, without conflicts with
generated files etc.) And it also shows how to access "special folders"
on Windows such as "My images" etc.
I will put it on a server later on for other people to download in the
future. It is intended to be used as a base project and adapted to your
needs.
Cheers, Oliver
Attachment:
Attachment:
AppFramework-1.0.0.zip
Description: Binary data
Message 2 in thread
Till Oliver Knoll schrieb:
> ...
> * a simple bin directory which contains everything needed for running
> the app on a naked target system (1), with a private assembly of
> the C++ runtime libs, as described in the MSDN docs.
I actually forgot the footnote (1) which is not so unimportant actually.
Other people have reported that the manifest stuff is buggy, and now I
also start to believe in this theory. At least I did the following
observation with the "AppFramework" when built with Visual Studio 2005 SP1:
I tested the binary, together with the private assembly of the C++
runtime, on a naked (= no C++ runtimes preinstalled) Windows 2000,
Windows XP Home and Windows XP. The application started as expected.
But on a naked *japanese* Windows XP an error message popped up just
after clicking the *.exe! I must admit that my japanese is not so good
these days ;) but I believe it is the same error as "The application
could not be initialised. Please reinstall bla bla...", that is when
there is trouble with the manifest files.
Needless to say that when using the Setup project (which detects
automatically whether the vcredist_x86.exe needs to be installed or not)
the same application ran on the japanese Windows XP! That is when the
C++ runtime is installed The Right MS Way(tm) as a system-wide assembly
then it works!
I have also noted that on certain Windows XP machines trying to run the
application directly from a *shared folder* (again with the private
assembly as mentioned above) does *not* work: the same "Could not
initialise..." error message appears.
But on others (such as my developer box) it *does* work! We did not go
into details of how the shared folder was mapped etc. (it was the same
*.exe location though we were trying to execute), maybe some user/file
permission issues (off course every user had apparently at least *read*
permissions), some file server settings which were seen differently on
the respective Windows clients, I don't know. But as soon as one copied
the folder onto a local drive the *.exe worked also on the machines
which refused to start it from a network mapped drive!
The morale of the story: it seems that you are on the safe side when
using the vcredist_x86.exe, the other solution just seems to work in
about 97.341% of all cases ;)
It's so much fun, you know... :-0
Cheers, Oliver
--
[ signature omitted ]