Forums

Hi threre,

my first post in this forum and then it's no classical POL_Install-script: Shame on me!

But there is a thing I really would like to share my thoughts with you.

From time to time I would like to solve the riddle how to realize a deb-Installation of a Programm that runs wih the help of wine.

POL is.. let me first thank you POL-Programmers... a great improvement to wine
since  the descision of creating dedicated wineprefix per program and linking it
toghether with a fitting version of wine is *the* base of my thoughts how to go
further.

So it's no question that POL provides the base of my scripts.

What I have done so far?

1. I installed  an application in POL and made it work there ( winetricks, settings etc. )
2. I put wineprefix and wineversion to centralized places in /opt/. I used a stucture like /opt/wineports/<Manufacturer-Dir>/<Program-Dir>/.
   
3. A startscript takes care on creating a home-Folder structure, which reflects the  /opt/ structure via symlinks and creating pyhsical directories in home folder to enable the game to deal with changing data, such as inis or savegames.
4. Further the script handles setting the WINE-Environment variables and runs the program in it's prefix which is the home-structure that is linked mainly to /opt/
   

Example wpstartnpp.sh (Notepad++):

#!/bin/bash

# set basic opt path of application
PROG_OPT_DIR="/opt/wineports/NotepadplusplusTeam/Notepadplusplus"
PROG_HOME_DIR="$HOME/.wineports/NotepadplusplusTeam/Notepadplusplus"
PROG_WINE_DIR="$PROG_OPT_DIR/wine"
PROG_WINE_BIN="$PROG_WINE_DIR/bin"

# set base environment variables
export PATH=$PROG_WINE_BIN:$PATH
export LD_LIBRARY_PATH=$PROG_WINE_DIR/lib:$PROG_WINE_DIR/lib/fakedlls:$LD_LIBRARY_PATH
export WINEPREFIX="$PROG_HOME_DIR/prefix"
export WINEDLLPATH="$PROG_WINE_DIR/lib/wine"
export WINELOADER="$PROG_WINE_BIN/wine"
export WINESERVER="$PROG_WINE_BIN/wineserver"
export PREFIX_PROG_DIR="$WINEPREFIX/drive_c/ProgramFiles/Notepad++/"
export OPT_PROG_DIR="$PROG_OPT_DIR/prefix/drive_c/ProgramFiles/Notepad++/"
export OPT_SEARCH_DIR=$PROG_OPT_DIR/prefix/drive_c/ProgramFiles/Notepad++/
export WINEPORTS_MAXDEPTH_SEARCH=5
export WINEPORTS_DOS_STARTPATH="c:ProgramFilesNotepad++notepad++.exe"
# export WINEPORTS_SHARE_FOLDER="/usr/share/wineports/PiranhaBytes/Gothic/"


function SetupHomeEnvironment()
{
  # create symlinks for dosdevices
  mkdir -p $WINEPREFIX/dosdevices/
  local C_LINK="$WINEPREFIX/dosdevices/c:"
  local C_TARGET="$WINEPREFIX/drive_c/"
  local Z_LINK="$WINEPREFIX/dosdevices/z:"
  local Z_TARGET="/"
  ln -s $C_TARGET $C_LINK
  ln -s $Z_TARGET $Z_LINK
  
  # create basic home folder for placing all symlink-elements in  
  if ! [ -d "$PREFIX_PROG_DIR" ] ; then
    mkdir -p "$PREFIX_PROG_DIR" 
  fi
  
  # search source dir for all folders and subfolders in configured depth
  # @TODO: Search delivers too much results in subfolders
  EMPTY_REPLACEMENT=""
echo $OPT_SEARCH_DIR
echo "find $OPT_SEARCH_DIR -maxdepth $WINEPORTS_MAXDEPTH_SEARCH -type d -print0 -printf "%h;""
  RecursivePathSearch="$(find $OPT_SEARCH_DIR -maxdepth $WINEPORTS_MAXDEPTH_SEARCH -type d -print0 -printf "%h;")"
echo $RecursivePathSearch
  OrigIFS=$IFS
  IFS=";"
  ArrayPathSearch=($RecursivePathSearch)
# echo ${ArrayPathSearch[@]}
exit 0

  COUNTER=0
  for CurrentPath in ${ArrayPathSearch[@]} ; do
    if ! [ -e "$CurrentPath" ] ; then
      if [ "$COUNTER" != "0" ] ; then
        # remove opt-path
	RelativePath="${CurrentPath//$OPT_PROG_DIR/$EMPTY_REPLACEMENT}"
	# Switched off escaping due it does not create exprected results
	# EscapedRelativePath=$(echo $RelativePath | sed 's/ /\ /g')
	CreateHomePath "$RelativePath"
	LinkSubpath "$RelativePath"
      fi
      let COUNTER=COUNTER+1
    fi
  done

  IFS=$OrigIFS    
}

function LinkSubpath() {
  local SubOptPath="$OPT_PROG_DIR$1"
  local SubHomePath="$PREFIX_PROG_DIR$1"
echo $SubOptPath
  # search files in opt path if opt-path exists and link home links to corresponding opt-files
  if [ -e "$SubOptPath" ] ; then
    # echo "find $SubOptPath -maxdepth 1 -type f ( ! -iname ".*" ) ( ! -iname "*~" ) -printf "%f;""
    FileSearchResult=$(find $SubOptPath -maxdepth 1 -type f ( ! -iname ".*" ) ( ! -iname "*~" ) -printf "%f;")
    # echo $FileSearchResult
    OrigIFS=$IFS
    IFS=";"
    ArrayFileSearch=($FileSearchResult)
    COUNTER=0
    for CurrentFile in ${ArrayFileSearch[@]} ; do
	if ! [ -e "$SubHomePath/$CurrentFile" ] ; then
	  echo "ln -s $SubOptPath/$CurrentFile $SubHomePath/$CurrentFile"
	  ln -s $SubOptPath/$CurrentFile $SubHomePath/$CurrentFile
	fi
    done  
    IFS=$OrigIFS
  fi
}

function CreateHomePath() {
  local CreatePath="$PREFIX_PROG_DIR$1"
  if ! [ -d "$CreatePath" ] ; then 
    echo "mkdir -p $CreatePath"
    mkdir -p $CreatePath
  fi
}

function CreatePath() {
  local CreatePath="$1"
  if ! [ -d "$CreatePath" ] ; then 
    mkdir -p $CreatePath
  fi
}

function CopyConfig() {
  echo "Copy ini files from share to home folder"
}

function RunApplication() {
  winedbg $WINEPORTS_DOS_STARTPATH
}



CreatePath "$PROG_HOME_DIR"
CreatePath "$WINEPREFIX"

SetupHomeEnvironment
RunApplication

This script has currently the problem of not beeing able to reflect 
the complete sructure. It misses some dirs.

I really would like to improve this whole Idea by centralizing only 
the wineprefix directly inside the POL-Home-Folder and let POL take 
care on the wineversion and execution of the program.

A central installation of wine-programs is possible as seen at 
teamviewer which is a wineport installed via apt. But what I search 
for is a more POL-Way and use it's structure.

I would be glad to share my thoughts with you and are interested in
your ideas. 

Have you tried to realize similar tasks? Are there any security related 
issues by using the symklink method, that I described here?

Let me know !

Best wishes,

André 

Edité par amherrmann

Hello again,

it seems I found a way to reach my goal of having system wide installations of
wine-programs. As mentioned in my previous comment, I began not just to see
playonlinux as the framework, that can create prefixes and wine versions for me. I
wanted to make use of the framework more directly.

Following that mantra, I was able to write a little python class, that is able to create a
"fake environment" for a wineprefix in playonliux's home folder. This environment
consists of directories and symlinks which the script is able to create while starting the
program. This means every user, who runs this (start-)script, is using the binaries
placed in /opt/ by pretending to be in home.

Another folder in /opt/ contains the playonlinux initial config files which will be copied
once (or per initial reset) into the environment. Also writable folders and files should be initially placed here to recreate writable folder structures in home which the program expects to be writable.

A final conclusion fo the script should be the ability for creating a wineprefix, downloading needed libraries or a wine-version. Luckily you POL-girls and -guys invented "playonlinux-bash" :-)

If I manged to add 1 and 1 together, I will post my solution here.

Just wrote that stuff to keep you informed about the other approach, which seems to be more promising.

Thanks to all Co-thinkers so far and still any comments and opinions are welcome :-)

Best wishes,

Edité par amherrmann

Hi,

here's the script which creates a folder-/symlink-structure in pol home directory. Unfortunately I noticed, that it did not create all folders and symlinks, so I will improve that soon.

Here's what I did so far:

#!/usr/bin/python

import os
import shutil
"""
WinePortEnvironment class which is able to create fake environments
which enable PlayOnLinux to run a wineprefix, which is placed in opt
"""
class WinePortEnvironment:
     
     def __init__(self):
          self.dictLinkPaths = {}
          # initialize defaults
          self.sCurrentPath = ""
          self.sProgramOptPrefix = ""
          self.sProgramOptPrefixConfig = ""
          self.sProgramPolPrefix = ""
          self.sHomeDir = os.environ['HOME']
          
          
     def getHomeDir(self):
          return self.sHomeDir

     def getOptPrefix(self):
          return self.sProgramOptPrefix

     def getPolPrefix(self):
          return self.sProgramPolPrefix
     
     def setCreatePolBaseStructure(self):
          try:
               os.mkdir( self.sProgramPolPrefix )
          except os.error, err:
               pass
          aPaths = []
          for sRootDir, aSubFolders, aFiles in os.walk( self.sProgramOptPrefixConfig ):
               for sFile in aFiles:
                    aPaths.append( sRootDir + "/" + sFile )
               
          for sCopySource in aPaths:
               sRelativePath = sCopySource.replace( self.sProgramOptPrefixConfig, "" )
               sCopyTarget = self.sProgramPolPrefix + sRelativePath
               shutil.copyfile( sCopySource, sCopyTarget )
               #print "COPY " + sCopySource + " TO " + sCopyTarget
     
     def setCreatePolFolderStructure(self):
          if self.sProgramOptPrefix != "":
               aPaths = self.walkThroughPath( self.sProgramOptPrefix, True, False )
               for sPath in aPaths:
                    sHomePath = self.getHomePathOfOptPath( sPath )
                    try:
                         os.mkdir( sHomePath )
                    except os.error, err:
                         pass          

     def setCreatePolSymlinkStructure(self):
          if self.sProgramOptPrefix != "":
               aPaths = self.walkThroughPath( self.sProgramOptPrefix, False, True )
               for sPath in aPaths:
                    sHomePath = self.getHomePathOfOptPath( sPath )
                    try:
                         os.symlink( sPath ,sHomePath )
                         # print sPath + " => " + sHomePath
                    except os.error, err:
                         pass               

     def getHomePathOfOptPath( self, sPath ):
          sRelativePath = sPath.replace( self.sProgramOptPrefix, "" )
          return self.sProgramPolPrefix + sRelativePath

     def setProgramOptPrefix(self, sProgramOptPrefix):
          self.sProgramOptPrefix = sProgramOptPrefix

     def setProgramOptPrefixConfig(self, sProgramOptPrefixConfig):
          self.sProgramOptPrefixConfig = sProgramOptPrefixConfig

     def setProgramPolPrefix(self, sProgramPolPrefix):
          self.sProgramPolPrefix = self.sHomeDir + "/.PlayOnLinux/wineprefix/" + sProgramPolPrefix

     def walkThroughPath(self , sBasePath, blFolders = True, blFiles = True ):
          aPaths = []
          for sRootDir, aSubFolders, aFiles in os.walk( sBasePath ):
               for sFolder in aSubFolders:
                    if blFolders == True:
                         aPaths.append( sRootDir )
                    for sFileName in aFiles:
                         if blFiles == True:
                              aPaths.append( sRootDir + "/" + sFileName )
               
          return aPaths
     
     
# main
oWinePortEnvironment = WinePortEnvironment()
print "Instance created..."
oWinePortEnvironment.setProgramOptPrefix( "/opt/wineports/Mateso/PasswortSafeRepository/prefix" )
oWinePortEnvironment.setProgramOptPrefixConfig( "/opt/wineports/Mateso/PasswortSafeRepository/prefixconfig" )
oWinePortEnvironment.setProgramPolPrefix( "PasswortSafeRepository" )
print "Pathes assigned..."
oWinePortEnvironment.setCreatePolBaseStructure()
oWinePortEnvironment.setCreatePolFolderStructure()
oWinePortEnvironment.setCreatePolSymlinkStructure()
print "Environment created..."

Hi,

You'll always have a problem: wine is a user program, and a wine prefix owned by a user cannot be used by another one.

If you want to bypass this, you'll have to patch one, but it is not a good idea in most cases

Hi,

You'll always have a problem: wine is a user program, and a wine prefix owned by a
user cannot be used by another one.

If you want to bypass this, you'll have to patch one, but it is not a good idea in most cases

Edité par amherrmann

Hi again,

I added some code to sourceforge, so I am able to present it without posting more and more code here :-)

the problem with the amount of files I meantioned above is now solved.

My recent problem that I have (and Tinou could have meant) is that the wineprefix I start is not noticing my application. The prefix behaves as if it nothing is installed, which could have been expected due wineprefix-registry does not know anything about the installed application While executing in debug mode it will tell you:

[09/21/13 21:38:50] - Running wine-1.7.2 psr.exe (Working directory : /home/andre/.PlayOnLinux)
wine: cannot find L"C:\windows\system32\psr.exe"

So I assume my last problem to solve is to understand what registry entries have to be modified to make wineprefix knowing the application and also know what has to be executed.

Unfortunatly I am no registry hacker. I found a page of the wine-project which deals with the registry, but I did not find an attemt for me to solve my issue:
http://www.winehq.org/docs/wineusr-guide/using-regedit

My testing application is "Password Safe Repository" of Mateso, but in the end the scripts shall be work by configuration. Here's the scripting I did for reaching my goal:

Startpoint:
https://sourceforge.net/p/wineportscripts/code/HEAD/tree/trunk/experiments/psr/wineportstart.py

Class that is used by the startscript:
https://sourceforge.net/p/wineportscripts/code/HEAD/tree/trunk/experiments/psr/pol_wineport_environment.py

POL-Script to create the prefix and download the needed wineversion:
https://sourceforge.net/p/wineportscripts/code/HEAD/tree/trunk/experiments/psr/CreatePrefixPasswordSafeRepository.sh

POL-Script for creating a shortcut (not working currently):
https://sourceforge.net/p/wineportscripts/code/HEAD/tree/trunk/experiments/psr/CreateShortcutPasswordSafeRepository.sh

Entry for playonlinux application list (Quick hack):
https://sourceforge.net/p/wineportscripts/code/HEAD/tree/trunk/experiments/psr/PasswortSafeRepository

I really hope someone of you knows an attempt to solve the issue of ghost installations. I tried to add some registry entries to wineprefix manually by using regedit but as said, I am no registry hacker :-)

Best,

Edité par amherrmann

Hi,

I finally found the error and the concept now seems to work !!! Yes !!!

I simply had a wrong path in my entry for POLs application list *facepalm*

Now I am able to delete the whole wineprefix in my home, start the script and the whole prefix will be recreated and I am able to start the program then :-)

I will have to do some further research on the registry thing too. I made some diffs yesterday and realized that entries in system.reg only had a different timestamp then those I prepared in opt-config-folder.

I hope I can present a debian package of a POL installation soon.

Best,

Updated scripts:

Added support for running script as a different user. Registry Settgins were not nessessary.

Revision 3:

http://sourceforge.net/p/wineportscripts/code/HEAD/tree/trunk/experiments/psr/

Ive actually thought about this; a stand-alone, POL based prefix creator. Its sounds great, but there are multiple variables that have to be considered. User rights and ownership, as stated above by Quentin (hey there, by the way. lol), are going to cause all sorts of headaches. The dependent libraries that need to be installed arent that big of a deal, but but if anything else happens during install, how are we going to know? Debug output from wine is vague to say the least, and I doubt we could easily and efficiently shrink the Python and BASH functions all down to a manageable enough size to facilitate this without weighing down the system.

As Wine gets better, the need for multiple prefixes will go bye-bye. Ideally, Wine should run without user interaction, but this obviously is not that case (yet. Its gotten MUCH better recently). This is why things like POL and Winetricks are available, and wine has the functions to create its own prefixes and things of that nature.

I really do believe that your idea is possible through some coding and whatnot. If you can think it, you can do it, provided you can program/script.

As for programs to test, go and grab a copy of League of Legends and try it like that.

Now, another thing, how are you going to prompt the user for install disc, install file, or install media in general? You will need some very fancy BASH to have it do so automatically without user intervention. Perhaps leave your program to create the drive, but then at the very end, prompt the user for install disc? But then again, you have the problem of 32 vs 64 bit info, and debugging output for it.

Im very interested to see what you come up with :)

Hi Yosha,

Ive actually thought about this;
a stand-alone, POL based prefix creator. Its sounds great, but there
are multiple variables that have to be considered. User rights and
ownership, as stated above by Quentin (hey there, by the way. lol), are
going to cause all sorts of headaches. The dependent libraries that need
to be installed arent that big of a deal, but but if anything else
happens during install, how are we going to know? Debug output from wine
is vague to say the least, and I doubt we could easily and efficiently
shrink the Python and BASH functions all down to a manageable enough
size to facilitate this without weighing down the system.

As
Wine gets better, the need for multiple prefixes will go bye-bye.
Ideally, Wine should run without user interaction, but this obviously is
not that case (yet. Its gotten MUCH better recently). This is why
things like POL and Winetricks are available, and wine has the functions
to create its own prefixes and things of that nature.

First: I want to see my approach as addition to POL, not as a replacement. The
demand on wine that it simply should run anything without the need of
third-party libraries is correct, but I guess we'll need to live with
this state of development, so let's be pragmatic here and look
forward to any wine-release upcoming :)

I
really do believe that your idea is possible through some coding and
whatnot. If you can think it, you can do it, provided you can
program/script.

As for programs to test, go and grab a copy of League of Legends and try it like that.

I
recently tested the LeagueOfLegends POL-Script which really works well
and installs nearly automatically. I will consider this in future, but
for my first attempts I will choose Free Licensed Programs because I
don't wanna be sued to the bone ;-)

Now,
another thing, how are you going to prompt the user for install disc,
install file, or install media in general? You will need some very fancy
BASH to have it do so automatically without user intervention. Perhaps
leave your program to create the drive, but then at the very end, prompt
the user for install disc? But then again, you have the problem of 32
vs 64 bit info, and debugging output for it.

As
said the concept of centralized prefixes seems to work well. The
complete prefix is already inside the debian package in /opt/. So no
install-media is needed for this kind of install :-) Currently I only use 32-Bit Installations to ease things while testing/developing.

Im very interested to see what you come up with :)

I
hope I can provide a package and a step-by-step guide soon ('til end of
the week or so) that anyone of you is able to install and check the
code and implementation :-)

Nontheless, there have been some issues with my test-application
my testers reported to me, which are mostly fixed in Revision 5.


What I currently have to deal with is:

1. Current debian
packages will need PlayonLinux in version 4.2.1 (because of the need of
playonlinux-bash). Most distros have older versions. Due I want to have
the install as easy as possible, I consider to create a ppa which
contains a recent playonlinux version, so POL would be upgraded
automatically when installing the wined/poled application. For testing
this won't be nessessary.

2. Before my test-application can be
started. POL has to be started at least once to init everything in
/.PlayOnLinux/. I will add a check for the existance of .PlayOnLinux and
tell the user to initially start POL, before going on starting the
application. This is pragmatic, but of course I would like to automate
that too if possible. Is there a way to init POL-Environment via script?

Best wishes,

André

Edité par amherrmann

So here it is the first example.

Please remember that this is an early state of development and shouldn't nessessarily be installed in a productive system! Do as I do and use a virtual machine for testing ;)

So lets go then:

Pre-Conditions:

Currently I just have tested this in ubuntu 12.04 desktop. Debian could work too.

It is still nessassary that you have at playonlinux >= 4.2.1 (See Downloads) installed and at least startet once ( standard playonlinux initiliazation ).

Installing the base library package (wineports):

Download the package from

http://sourceforge.net/projects/wineportscripts/files/wineports-0.0.2_all.deb/download

and install it via your package management. This package provide some functions for creating the pol home environment.

Installing the application package (Notepad++):

Download the package from

http://sourceforge.net/projects/wineportscripts/files/notepad%2B%2B_multilang-6.4.1_all.deb/download

and install it via your package management. This is the pol application that will run for any user (installed system wide).

Starting the application Notepad++:

After installing the application there should be a menu entry "Notepad++" in section utilities of your DE.

On first start anything will be initialized a way POL users should be familiar with when creating a new prefix and downloading needed wine version.

The application should automatically start after initializing.

At this point you can either start the application via DEs menu or PlayOnLinux installed application list.

Please test and report bugs or feature requests to:
https://sourceforge.net/p/wineportscripts/tickets/

Best wishes,

André

Edité par amherrmann

Update:

I managed to pack NeverwinterNights_gog as a debian package and it worked! :D

Of course I cannot pblish this package. It was just the proof of concept for games.

I bought this game on gog and installed it via the provided script (which worked nearly perfect => nearly, because an option to pause downloads would be a great improvement. Then it would be absolutely perfect)

However, this prefix was my template for the package (as in my other test candidates)

I copied the drive_c into opt of my package, adjusted pathes, scripts and control file and build the package, which had a size of 3,1 GB in the end.

I was able to install this package on my other computer and could start to play the game. I will give it another try at a friend of mine.

The only problem that occured on my install attempt is, that software-center declined the package by saying that it could not open the package. Installing via dpkg -i worked without problems. Will check this with qApt again.

So what's next?

1. Creating a source-list: Publishable (license) packages should come at least as a sources-list. Currently I just have quick and dirty package builds via dpkg -b.
2. Creating a PPA: I plan to provide a ppa in the future leave the way of creating "quick and dirty" packages and go the way of providing software an acceptable way.

Unfortunatly the time I can put in this project might be lesser in the nearer future. Beside job and family with 3 kids, I recently was accepted for an IT-Security study alongside my job.

That means I really could need help in any way to go on bringing this project to success.

This could be:

• Suggests for software that is unproblemeatic for publishing
• Help for creating the PPA (should include the latest version of POL too)
• Testing the provided package and give feedback as ticket
• Let people who might be interested in this project know about what I try to do

I will set this topic as solved.

Best wishes to all of you

André

Edité par amherrmann

Hi , 

 

Will test your work for office 2010 , it's a great project !

Another option would be to patch Wine such that the Wineprefix could be "split." That is, make Wine load the registry (and therefore environmental variables) from registry files in a user's home directory. With environmental variables controlled in that way, it would be possible to simply make the registry in each user's home directory give environmental variables pointing to specific parts of the home directory.

For example, for the first run of a program for a user, it would copy the program's Wineprefix's registry from /opt and place it in ~/.<program name here>, and load the registry from there rather than from /opt whenever being run as that user. The registry in ~/.<program name> would then have to be modified for each user so that all the %CSLID_DEFAULT_*% variables pointed to folders in in their individual home directories, rather than to /opt. (e.g. %CSLID_DEFAULT_APPDATA% would point to Z:\home\<username>\.<program name>) Ideally, "system-wide" variables (%CSLID_COMMON_*%) would only hold locations neded for writing files during during the installation of a Windows program, and could remain pointing to /opt, where there would be read but not write access. Also in /opt could be Program Files, Windows, and any other directories that Wine creates that are "system-wide" on a real Windows system. That is, the Documents and Settings directory would need to exist, but only have an All Users directory inside. As far as I can seem this would work for most well-written, modern programs that do NOT need to be run as administrator in Windows.

While your solution is definitely simpler and better integrates with PlayOnLinux, my solution would make the application almost completely follow traditional Unix-like organization---that programs wouldn't be executed in the home directory, but configuration files would be stored there.

Does that sound possible? Is it worthwhile? It seems that it would only affect where Wine loads the registry from, and maybe some editing of the "per-user" registry on the part of whatever script (or PlayOnLinux) that starts the application. Unfortunately, I would not be of much help with this patch. (If it needs one---maybe there's a way to set the location of registry files for Wine.)