Peter Beck | 3 Dec 00:00 2011
Picon

change wpkg-gp installer text

Hello guys,

With wpkg-client it is possible to set a self-definied window title 
which will be displayed at start-up.

Wpkg-gp installer displays "Wpgk-GP is installing...." - is it possible 
to change this text ? I did not find any information about that.

Thanks
Peter
-------------------------------------------------------------------------
wpkg-users mailing list archives >> http://lists.wpkg.org/pipermail/wpkg-users/
bugzilla-daemon | 5 Dec 15:23 2011

[Bug 258] New: Windows 7 64 bit not correctly detected

http://bugzilla.wpkg.org/show_bug.cgi?id=258

           Summary: Windows 7 64 bit not correctly detected
           Product: WPKG
           Version: 1.2.1-RCx
          Platform: PC
        OS/Version: other
            Status: NEW
          Severity: critical
          Priority: P2
         Component: wpkg.js
        AssignedTo: mangoo <at> wpkg.org
        ReportedBy: bruno.choquet <at> unicaen.fr
         QAContact: wpkg-users <at> lists.wpkg.org

Hello,

With the version WPKG 1.2.1-RC49 my Windows 7 64 bit (french) is detected as
x86 and not x64 : 

011-12-05 15:09:10, DEBUG   : Host properties:
hostname='test128254'|architecture='x86'|os='microsoft windows 7 professionnel,
, sp1, 6.1.7601'|ipaddresses='xxx.xxx.xxx.xxx'|domain
name='enseignement.local'|groups='Ordinateurs du
domaine'|lcid='40c'|lcidOS='40c'

--

-- 
Configure bugmail: http://bugzilla.wpkg.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
(Continue reading)

bugzilla-daemon | 5 Dec 15:54 2011

[Bug 258] Windows 7 64 bit not correctly detected

http://bugzilla.wpkg.org/show_bug.cgi?id=258

Rainer Meier <r.meier <at> wpkg.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |ASSIGNED
                 CC|                            |r.meier <at> wpkg.org

--- Comment #1 from Rainer Meier <r.meier <at> wpkg.org>  ---
Are you able to reproduce this by switching between WPKG 1.2.0 and 1.2.1-RC49?

I am asking because on all my Win7 Pro x64 machines the architecture is
detected properly:

2011-12-04 12:17:50, DEBUG   : Host properties:
hostname='pc01'|architecture='x64'|os='microsoft windows 7 professional, , sp1,
6.1.7601'|ipaddresses='0.0.0.0,10.0.1.168,192.168.56.1,10.0.1.113'|domain
name='domain'|groups=''|lcid='807'|lcidOS='409'

Moreover the code to detect the host architecture has not been changed since a
while. WPKG is using the value of %PROCESSOR_ARCHITECTURE% system environment
variable to detect the architecture. Is it set to "AMD64" on your system?

Maybe you have set up Windows 7 32-bit on a x86 hardware. In this case Windows
reports "x86" as a value of PROCESSOR_ARCHITECTURE, even if the hardware is
capable of x64/AMD64/EM64T instruction set.

br,
Rainer
(Continue reading)

bugzilla-daemon | 5 Dec 16:37 2011

[Bug 258] Windows 7 64 bit not correctly detected

http://bugzilla.wpkg.org/show_bug.cgi?id=258

bruno.choquet <at> unicaen.fr changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
         Resolution|                            |FIXED

--- Comment #2 from bruno.choquet <at> unicaen.fr  ---
Oups, sorry, it' my fault !!!

Wpkg Client 32bit installed on windows 7 64bit cause this reaction :
architecture is detected as x86.

With Wpkg Client 64 bit installed on windows 7 64bit, architecture is correctly
detected as x64.

--

-- 
Configure bugmail: http://bugzilla.wpkg.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
-------------------------------------------------------------------------
wpkg-users mailing list archives >> http://lists.wpkg.org/pipermail/wpkg-users/
Steve Kersley | 5 Dec 18:29 2011
Picon
Picon

MSIs, install paths and different architectures

This is probably more of a 'share the frustration' post than anything specifically wpkg-related, but very
keen to hear if anyone has a workaround?

I have an application (Samsung MagicInfo Premium Authoring tool - the user tools for our digital signage
system) that needs to be installed in the same folder on each machine as the data files that it creates
contain hardcoded paths to content files stored in the local install directories.  If you open these files
on a different architecture to the machine that created them, the files aren't in the same place ("Program
Files" vs "Program Files (x86)") so won't open correctly.

Most of our PCs are currently running x86, but a couple of us (myself included, and I'm the one who creates the
initial content template and then hands off to other people to maintain and edit) are running x64 and the
intention is that in future staff PCs will be replaced/migrated from XP to Windows 7 x64.

I have extracted the MSI from the InstallShield installation source, and it does support the INSTALLDIR
property via the msiexec command line.  However, Windows is being too clever.  It will let me install to
c:\foo, but if I tell it to install to c:\Program Files\foo, it silently modifies that so that it installs
to c:\Program Files (x86)\foo instead.

Is there any way to forcibly install a 32-bit app into c:\Program Files on an x64 machine?

Is the only option going to be the slightly messy approach to install to a new directory in the root of c:?  That
will mean having to modify the existing data files that have already been authored, but will only have to be
done once, before we create too many more.

I have also considered creating a symlink or junction within \Program Files to point to the subdirectory in
\Program Files (x86) - that works in that it would allow a data file created on an x86 machine to be opened on
an x64 machine but still won't work the other way round unless I create an unnecessary "Program Files
(x86)" directory tree on all of the x86 machines too.

Has anyone dealt with a similar problem?  I think the fault is largely with the application, but really it
(Continue reading)

bugzilla-daemon | 5 Dec 19:03 2011

[Bug 258] Windows 7 64 bit not correctly detected

http://bugzilla.wpkg.org/show_bug.cgi?id=258

Rainer Meier <r.meier <at> wpkg.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |CLOSED

--- Comment #3 from Rainer Meier <r.meier <at> wpkg.org>  ---
Oh, I did not even think about this. But sure this is a good explanation too :)

Closing this issue.

--

-- 
Configure bugmail: http://bugzilla.wpkg.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
-------------------------------------------------------------------------
wpkg-users mailing list archives >> http://lists.wpkg.org/pipermail/wpkg-users/
Joe | 5 Dec 19:49 2011

Re: [Bug 258] Windows 7 64 bit not correctly detected

On 12/5/2011 1:03 PM, bugzilla-daemon <at> bugzilla.wpkg.org wrote:
> http://bugzilla.wpkg.org/show_bug.cgi?id=258
>
> Rainer Meier<r.meier <at> wpkg.org>  changed:
>
>             What    |Removed                     |Added
> ----------------------------------------------------------------------------
>               Status|RESOLVED                    |CLOSED
>
> --- Comment #3 from Rainer Meier<r.meier <at> wpkg.org>   ---
> Oh, I did not even think about this. But sure this is a good explanation too :)
>
> Closing this issue.
>

Is that the proper behavior?  Should a 64bit machine be detected as 32bit
because of the client software?
-------------------------------------------------------------------------
wpkg-users mailing list archives >> http://lists.wpkg.org/pipermail/wpkg-users/
Alan Adams | 5 Dec 19:59 2011
Picon

Re: [Bug 258] Windows 7 64 bit not correctly detected

In message <4EDD1224.3060500 <at> freakyacres.com>
          Joe <joe <at> freakyacres.com> wrote:

> On 12/5/2011 1:03 PM, bugzilla-daemon <at> bugzilla.wpkg.org wrote:
>> http://bugzilla.wpkg.org/show_bug.cgi?id=258
>>
>> Rainer Meier<r.meier <at> wpkg.org>  changed:
>>
>>             What    |Removed                     |Added
>> ----------------------------------------------------------------------------
>>               Status|RESOLVED                    |CLOSED
>>
>> --- Comment #3 from Rainer Meier<r.meier <at> wpkg.org>   ---
>> Oh, I did not even think about this. But sure this is a good
>> explanation too :)
>>
>> Closing this issue.
>>

> Is that the proper behavior?  Should a 64bit machine be detected as 32bit
> because of the client software?

I imagine it is. I would not expect to be able to run a 64-bit 
application on a 32-bit OS, which is what would happen if the hardware 
determined the architecture type.

Alan

> -------------------------------------------------------------------------
> wpkg-users mailing list archives >>
(Continue reading)

Joe | 5 Dec 20:18 2011

Re: [Bug 258] Windows 7 64 bit not correctly detected

On 12/5/2011 1:59 PM, Alan Adams wrote:
> In message<4EDD1224.3060500 <at> freakyacres.com>
>            Joe<joe <at> freakyacres.com>  wrote:
>
>> On 12/5/2011 1:03 PM, bugzilla-daemon <at> bugzilla.wpkg.org wrote:
>>> http://bugzilla.wpkg.org/show_bug.cgi?id=258
>>>
>>> Rainer Meier<r.meier <at> wpkg.org>   changed:
>>>
>>>              What    |Removed                     |Added
>>> ----------------------------------------------------------------------------
>>>                Status|RESOLVED                    |CLOSED
>>>
>>> --- Comment #3 from Rainer Meier<r.meier <at> wpkg.org>    ---
>>> Oh, I did not even think about this. But sure this is a good
>>> explanation too :)
>>>
>>> Closing this issue.
>>>
>
>> Is that the proper behavior?  Should a 64bit machine be detected as 32bit
>> because of the client software?
>
> I imagine it is. I would not expect to be able to run a 64-bit
> application on a 32-bit OS, which is what would happen if the hardware
> determined the architecture type.
>
> Alan

So a 32 bit client running under windows 64 bit on 64 bit hardware
(Continue reading)

Stefan Pendl | 5 Dec 20:36 2011
Picon

Re: MSIs, install paths and different architectures

Am 05.12.2011 18:29, schrieb Steve Kersley:
> This is probably more of a 'share the frustration' post than anything specifically wpkg-related, but
very keen to hear if anyone has a workaround?
>
> I have an application (Samsung MagicInfo Premium Authoring tool - the user tools for our digital signage
system) that needs to be installed in the same folder on each machine as the data files that it creates
contain hardcoded paths to content files stored in the local install directories.  If you open these files
on a different architecture to the machine that created them, the files aren't in the same place ("Program
Files" vs "Program Files (x86)") so won't open correctly.
>
> Most of our PCs are currently running x86, but a couple of us (myself included, and I'm the one who creates
the initial content template and then hands off to other people to maintain and edit) are running x64 and
the intention is that in future staff PCs will be replaced/migrated from XP to Windows 7 x64.
>
> I have extracted the MSI from the InstallShield installation source, and it does support the INSTALLDIR
property via the msiexec command line.  However, Windows is being too clever.  It will let me install to
c:\foo, but if I tell it to install to c:\Program Files\foo, it silently modifies that so that it installs
to c:\Program Files (x86)\foo instead.
>
> Is there any way to forcibly install a 32-bit app into c:\Program Files on an x64 machine?
>
> Is the only option going to be the slightly messy approach to install to a new directory in the root of c:? 
That will mean having to modify the existing data files that have already been authored, but will only have
to be done once, before we create too many more.
>
> I have also considered creating a symlink or junction within \Program Files to point to the subdirectory
in \Program Files (x86) - that works in that it would allow a data file created on an x86 machine to be opened
on an x64 machine but still won't work the other way round unless I create an unnecessary "Program Files
(x86)" directory tree on all of the x86 machines too.
>
(Continue reading)


Gmane