The "Error reading archive..." message when running an application via Wine on Linux Rosa suggests that Wine might be having trouble accessing or interpreting the application's files, possibly due to compatibility issues, missing dependencies, or a corrupted installer. Here’s a step-by-step approach to troubleshoot and potentially resolve this issue:
Check Wine Compatibility
Ensure that the application (FW, which I assume is a Windows-based program) is compatible with Wine. You can search the Wine Application Database (AppDB) online by typing the full name of the "FW application" (e.g., "FileWave" or whatever it stands for) to see if others have successfully run it and what Wine version they used. If you provide the exact name of the FW application, I can search for specifics if needed.
Update Wine
Make sure you’re using the latest version of Wine, as newer versions often fix bugs and improve compatibility. To check and update Wine on Linux Rosa (which is based on ROSA Linux, a Mandriva derivative), open a terminal and run:
sudo urpmi.update -a
sudo urpmi wine
This updates your package sources and installs/upgrades Wine. If you’re using a specific version (e.g., Wine Staging), specify it like sudo urpmi wine-staging.
Install Missing Dependencies
Wine sometimes needs additional libraries to handle Windows applications. Install the 32-bit compatibility libraries, as many Windows apps are 32-bit:
sudo urpmi libwine
Also, consider installing winetricks, a helper script for Wine:
sudo urpmi winetricks
Then run winetricks and install common dependencies like corefonts, dotnet, or vcrun (e.g., winetricks vcrun2019), depending on what the FW application might need. Check the app’s documentation or website for system requirements.
Verify the Installer/File Integrity
The error might indicate a corrupted executable or archive. If you downloaded the FW app installer, verify its integrity (e.g., using an MD5 or SHA checksum if provided by the source). Re-download it if necessary. If it’s an archive (e.g., .zip, .rar), extract it manually using a tool like unzip or unrar on Linux Rosa before running it with Wine:
unzip filename.zip
wine setup.exe
Run Wine with Debugging Output
To get more details about the error, run the application in Wine with verbose output:
WINEDEBUG=+err,+warn wine path/to/your/FWapp.exe
Look at the terminal output for clues—terms like “missing DLL” or “access denied” might point to specific fixes (e.g., installing a DLL via winetricks or adjusting permissions).
Check File Permissions
Ensure the application files have proper permissions. In the terminal, navigate to the folder containing the FW app and run:
chmod +x FWapp.exe
ls -l
If the file isn’t executable or readable, adjust it with chmod or chown as needed.
Use a Fresh Wine Prefix
Wine uses a “prefix” (like a virtual Windows environment). A corrupted prefix might cause issues. Create a new one:
WINEPREFIX=~/.wine_new winecfg
Then run the app in this prefix:
WINEPREFIX=~/.wine_new wine path/to/FWapp.exe
Alternative: Specify Full Path
If you’re running wine FWapp.exe from a directory Wine can’t access properly, use the full path instead:
wine /home/yourusername/path/to/FWapp.exe
If none of these work, could you clarify what "FW" stands for (e.g., FreeCAD, FileWave, or something else) and share the exact command you’re using? That’ll help me narrow it down further. Also, let me know if the error message has more details—I can refine the solution based on that!
Thanks, Antonio !
Which Wine to install 32 or 64 ?
The FWH app you are testing is 32 or 64 bits ?
The program for Wine(Port Proton) is working fine. I noticed this feature:
After selecting from the POPUP menu, all the buttons TBUTOON, BTNBMP, etc. cease to be clickable (however, they do not receive the disable status).
This can be solved by opening msg info(111). After clicking the mouse on the control, the clickability of all buttons will be restored.
What could be the reason for this behavior ?
What is the action fired from the POPUP menu ?
Could you provide a screenshot ?
local oCl
private oWnd
oCl:=TGet():New(100, 100, " ", oWnd:aControls[1], 500, 20, replicate("X", 35),, ;
CLR_BLACK, RGB(245, 245, 245),,,, .T.,,,, .T.)
oBt:=TButton():New(0, oCl:nWidth-22,"...", oCl,, 20, oCl:nHeight-2,,,, .T.)
oBt:bAction:={||Mnu_Tls()}procedure Mnu_Tls
local st, dim:=getcursorpos(), mas:={"One","Two","Three"}
local oMen, oCl
MENU oMen POPUP 2007
for st=1 to len(mas)
if st>1
SEPARATOR
endif
MENUITEM oCl PROMPT mas[st]
oCl:bAction:=&('{||oWnd:aControls[1]:aControls[1]:cText(" '+ mas[st]+' '")}')
next
ENDMENU
ACTIVATE POPUP oMen OF oWnd AT dim[1], dim[2]
return oCl:bAction:=&('{||oWnd:aControls[1]:aControls[1]:cText(" '+ mas[st]+' '"), msginfo(123)}')Try to replace msginfo(123) with SysWait( 3 )
I determined that the POPUP menu was to blame for everything. If, after selecting from the menu, you do something like oWnd:Hide(), oWnd:Show() (:Refresh() does not help), then access to all elements of the window is restored. How do I intercept the menu closing event without selecting?
You may use oWnd:bMenuSelect = { | oMItemSelect, nFlags, nHMenu | ... }
That codeblock is evaluated when a popup menu closes.
Please use MsgBeep() from the codeblock to test when it is called.
getenv( "WINEPREFIX" )