CrossOver Support - Community Forums

Important Information These are community forums and not official technical support. If you need official support: Contact Us

CrossOver Mac
Discussion about CrossOver Mac

The following comments are owned by whoever posted them. We are not responsible for them in any way.

Back to Threads Reply to Thread

First post - A few things

First let me say i am please with CO, i tried it on Linux but now i have a Mac Mini, behaviour seems the same.

I would like to mention that the installation does not inform the user that it is ready, it could have failed as well, a message would be nice.
I forgot but i believe that you have to restart the OS after installation and since there is no message... :)

Then there is the issue of tempfiles, in my tool (not this one) i make use of tempfiles.
While the compiler prepares the logfile it does not write to this file and i can not determine an error.
I have the feeling it get's confused of the windows temp foldername and the full bottle folder somehow.
--
I could try this but it takes time, so i am checking if this all sound familiar otherwise i'll make some test apps.

Edwin,

You don't have to restart your OS after installing Crossover. Also, when installing windows applications in Crossover, Crossover will simulate a windows reboot to satisfy the needs of the program. In general, you shouldn't ever need to reboot on account of Crossover, unless there's some kind of catastrophic failure :(

I'm not entirely sure what's going on with your temp files. Is the tool you're using connected to Crossover in any way, or this is a wholly separate program that's now acting up since you installed Crossover? As you've probably noticed, Crossover stores installation logs in the [bottle]/drive_c/windows/temp directory.

There is no issue between mac and CO, no worries.

But my developmenttool uses the Windows temp folder heavily, actually a tempfolder in the Windows tempfolder.
When the project is closed it throws away all files.
I can test more myself but i'll do that later, i just polled if there is an issue with the way one should access the folder.
By using the Windows temp folder name like c:\windows\temp... or the full bottle folder (i forgot :) )
Since it's in a bottle aka sandbox i assume the app never has to deal with the real mac folder.
But the Windows open file dialog does show the full mac folder and i find that odd but also helpful if you need to access files on the mac(-side).

My only question is so far, should my app have enough using the ordinary Windows folder or is there something odd that it may need to access the temp files via the long foldername.
If you don't know, i'll figure it out.

Odd is though that the compiler does create it's log in this folder but any error or success is not written to that file.
I have nothing to do with the compiler, i didn't create that thing but my development tool depends on the errors (or success) shown in the log.
So that's one thing i really could mention about this.

I am in no hurry so i'll come back here, if you know about an issue..?
Otherwise i'll make me something for you to test.

Edwin,

I found a related issue.
I have an option to open a specific folder like the current custom tempfolder via ShellExecute()
In all my code where i return a folder i always add a slash, under windows passing such a foldername is working fine but not in CO like:

ShellExecute( 0, "open", "c:\windows\temp\pd1234\", "", "", %SW_SHOW )

Under CO i must strip the slash like: "c:\windows\temp\pd1234"

The bottle structure (and thus the "windows folder") aren't removed from the Mac, per se, they're just buried. Your application's file browser will automatically open to a "windows" folder inside the bottle, but you can easily browse up to the Mac's primary file system so you can save your files wherever you like, or open files that you've saved to your desktop.

Not knowing more about the application (other than it being unsupported, I presume), we really can't guess as to why the logs aren't being written correctly. Crossover just writes installation logs to the temp directory, but there should be no problem with your app writing to that directory, as well.

The bottle structure (and thus the "windows folder") aren't removed from the Mac, per se, they're just buried. Your application's file browser will automatically open to a "windows" folder inside the bottle, but you can easily browse up to the Mac's primary file system so you can save your files wherever you like, or open files that you've saved to your desktop.

Yes and to stress, this seems to work fine.

Not knowing more about the application (other than it being unsupported, I presume)
Huh?
My app (PwrDev) is supported but i guarantee nothing when a user wants to use it in an environment other than Windows (versions are shown on the supportpage).
No, the compiler is from PowerBASIC and is the one generating the logfile.

I'll see if i can compile the main bas file without folder so it takes the current folder.

For Windows sysinternals.com has a file access log tool, i'll see if this works on the mac (doubt it) but may you know of a similar tool.
The logfile is created but does not contain text (0 bytes).
Maybe it tries to append text each time but uses a wrong folder the 2nd time.

I am not that persistant towards codeweavers don't worry, but if i can find the cause.. it may help.

For example my issue with the ShellExecute() API, i wonder if this is something which will be 'fixed' or maybe get a 'don't care' status, it does behave different.

:)

Edwin,

Pardon - wrong thread for my post

Please Note: This Forum is for non-application specific questions relating to installation/configuration of CrossOver. All application-specific posts to this Forum will be moved to their appropriate Compatibility Center Forum.

CrossOver Forums: the place to discuss running Windows applications on Mac and Linux

CodeWeavers or its third-party tools process personal data (e.g. browsing data or IP addresses) and use cookies or other identifiers, which are necessary for its functioning and required to achieve the purposes illustrated in our Privacy Policy. You accept the use of cookies or other identifiers by clicking the Acknowledge button.
Please Wait...
eyJjb3VudHJ5IjoiVVMiLCJsYW5nIjoiZW4iLCJjYXJ0IjowLCJ0enMiOi01LCJjZG4iOiJodHRwczpcL1wvbWVkaWEuY29kZXdlYXZlcnMuY29tXC9wdWJcL2Nyb3Nzb3Zlclwvd2Vic2l0ZSIsImNkbnRzIjoxNzA4NjEzODE4LCJjc3JmX3Rva2VuIjoiZHV2QTg1UEJzVzJ0QUNIdyIsImdkcHIiOjB9