I have a weird problem with launching and running a C program in XCode. I create a command-line C program (the program just prints "Hello, World!\n"). The program is complied with no problem. How it does not print any output in the Debugger Console window when I run it (using the Run item in the Run menu).
I run XCode under my admin account, so there should not be problems with admin rights required to run XCode Debugger under non-admin accounts. The weird thing is that if I log in to another admin account (created for testing), then I have no problem running the program from within XCode: I see the line "Hello, World." as well as GDB's output.
I suspect that there's something wrong with my account (not the one created for testing), as I changed my account's shortname before. I would greatly appreciate it if someone here can give a glimpse of the problem and/or a possible fix.
Solutions that I have tried: using Disk Utility to repair permissions; using dscl to add me to the _developer group (but I don't think it actually helped as my account is admin); and reinstalling XCode.
My laptop is running OS X 10.6.8, and the version of my XCode is 3.2.6.
The reason that XCode Debugger hangs on my machine is that there is .gdbinit in my home directory that points to a GDB version different from that in XCode. I remove .gdbinit and the Debugger works again.
Related
Environment
macOS Catalina 10.15.7
Xcode 12.3
Problem
My macOS command-line application, written in C++, runs ok inside Xcode or as a standalone program in Terminal. But fails to launch when run as a child process from other programs.
The error message looks like this
Efforts
I've looked through my project's provisioning settings.
My team profile is only one-day past its life span. And the project still builds so I doubt that is the issue. I then switched to another certificate that is still healthy but saw the same problem with the child process failure.
I've also checked security settings and there are no permission blocks or anything like that. I've built this program many times and sorted out all the permission issues before. There used to be no problem running it as a child process.
Question
What am I missing?
Found the solution myself.
I had to remove the code signature using
codesign --remove-signature
Then sign it normally through Xcode.
It is most probably caused by our team switching signing identity and deprecating the old one.
Another related fix:
This error also happens when I run any script that launches child processes of executables built myself inside an IDE.
The solution is to add the IDE to
System Preferences > Security & Privacy > Privacy > Developer Tools
I'm trying to use "wine" on MAC osX Sierra version 10.12, wine is version 1.9.19
In the terminal I can launch Windows applications, however its a pain to have to keep typing in:
/Applications/Wine\ Staging.app/Contents/MacOS/wine ~/.wine/drive_c/Program\ Files/HeidiSQL/heidisql.exe
I've searched around for a post on how to create shortcuts/applications to add to the launchpad, but so far none of the information has led me to a working end result. Either the locations of wine is different or it just doesn't work.
I've tried creating an application script:
do shell script "/Applications/Wine Staging.app/Contents/MacOS/wine ~/.wine/drive_c/Program Files/HeidiSQL/heidisql.exe"
But this won't run either.
For anyone having the same problem, in the end I created scripts which reside in my home folder:
Launch vi, create a file called HeidiSQL, insert:
wine ~/.wine/drive_c/Program\ Files/HeidiSQL/heidisql.exe
Save and exit file, grant file execute permissions:
chmod +x HeidiSQL
Launch wine terminal and type in ./HeidiSQL to launch, I then did the same for PSPad.exe:
wine ~/.wine/drive_c/Program\ Files\ \(x86\)/PSPad\ editor/PSPad.exe
I know this thread is a little old but I was just looking for something like this to launch HeidiSQL and I came up with these three solutions which I have tried and all of them work. I am putting my findings down here for it may help someone:
Wineskin (http://wineskin.urgesoftware.com), Playonmac (https://www.playonmac.com/en) and Winebottler
(http://winebottler.kronenberg.org)
Wineskin is a mac app that download and install (and manages, updates, etc) "wine" for you. It then creates a HeidiSQL.app (any name you want with any icon you want - but you need to configure it) around the windows.exe that includes the wine version selected and is completely self contained (does not need wine installed separately). Personally this is the neatest solution and my preferred even though there its a little more technical than Playonmac and similar to Winebottler. You need to read the instructions (which are very good) and you have choices to make as to the wine version to use and to configure the app. Noteworthy is that you need to change the windows version to XP rather than 7 or some buttons won't work.
Playonmac on the other hand is very user friendly. It has HeidiSQL listed on its website as compatible and its almost a single click install. You just select HeidiSQL from the list of programs and it will download everything you need for you. The only reason I prefer Wineskin is that it does not create a true self contained HeidiSQL.app. You can create a shortcut for it in your Applications folder but this will launch Playonmac and the app needs to be installed inside Playonmac. On the plus side, Playonmac will chose all the right settings for you to run the app correctly, the correct windows and wine version etc which is something you need to fiddle with with with Wineskin.
Winebottler again makes an app like Wineskin. The only real difference I could see is that with Wineskin the configuration app is actually part of the package whereas in Winebottler you have to recreate the package each time you make a change. I stuck with Wineskin. YMMV.
I just recently upgraded to Windows 10 and ever since I have upgraded I can't get into VB6. I keep getting the System Registry error. I have googled and tried about everything and nothing seems to work. Running VB6 as Administrator is not an option, don't ask but we can't have admin to our computers we have to be logged in as users. The way we use to fix it was to trick Windows 7 log on as Admin run VB6 as Admin then switch me back to user and it worked, but this no longer works. Does anyone have any suggestions that currently have VB6 working as a user and not admin? I really don't want to resort to have to run it out of my virtual machine :( Thanks in advance!
Amanda,
I know it is 3 years later and I wonder what you did. and my solution may be late.
I moved VB6 Enterprise to a Windows10 machine, I did not upgrade the machine to Win10 with the IDE. However to make it work for some of my clients with Win10 machines I:
Back up all the VB6 files, folder and directories.
Using control panel in Win10, uninstall VB6 app. That's right, uninstall!
Using the original install disk, running it as an Administrator, install the program.
If the program has been updated to a later version, you need to get a copy of the latest version and copy over the one that was installed.
Or, Sweet Talk your IT guy into making you a new install disk with the latest version you are supposed to be running.
Go to the folder where the exe file is installed, Right Click on it and open the Properties, and go to the Compatibility tab.
Choose run as an administrator, and also click the Run this program in compatibility mode for Windows XP Service Pack3, or if it shows Latest version of Windows XP try that. You may need to check with your IT department.
Warning: if the VB6 program uses any non-Microsoft tools you may need to register them by hand.
I suspect this has already been worked out for you, but I put it here for anyone that may stumble across it, needing it.
I am trying to build a windows service that includes a Lua component, and links with Lua's shared libraries. I am building the code in Eclipse/CDT with MinGW. It builds fine, but when I run it, I get "Application failed to Initialize Properly (0x80000003). Click OK to terminate".
I am looking for clues as to what might be going on. A Hello World program compiles and runs fine, so there are no basic environment issues (I hope!). BTW, I am running on XP Home.
Update:
OK, I have figured out, by some guesswork, what was going on, and thought I'd post this for the benefit of others who might run into a similar problem - I think the lua DLL I was linking to, at runtime, was a different version than the one I built with. This caused the app initialization to fail I guess. When I made them to be the same file, things started working. I have not looked into why this would cause app init to fail, but I guess some symbol being at a different address or something? Or could it be that the DLLs were built with different tool chains?
This might be caused by not having permissions to access the DLLs required by the application. Are you logged in as an Administrator or member of the Administrator group?
Try logging in as Administrator to see if the problem goes away. This will help determine if it's a permissions issue, and then you can explore that further.
You could also try using the Dependency Walker (depends.exe) to see if this highlights any problems.
Cause of this problem is to try to run DOS programs, or 16-bit programs in Windows XP
To run DOS programs, or 16-bit environment in windows xp
To do so go to Start , Run and type gpedit.msc
And there go to:
User Configuration
Administrative Templates
Start Menu and Taskbar
And double-click on
Add "Run in Separate Memory Space" check box to Run dialog box
Select Enabled and then OK.
If the problem is not resolved, we will have to disable the Dr Watson , Do the following:
Go to the Start
Programs
Accessories
System Tools
System Information
Then go to:
Tools
Dr Watson
Or go to Start , Run and type drwtsn32
And disable:
Dump All Thread Contexts
And
Create Crash Dump File
And press:
OK
And then restart your computer .......
And then you will be able to run any game or program is running Dos or 16-bit, within Windows xp.
I have a setup project created by Visual Studio 2005, and consists of both a C# .NET 2.0 project and C++ MFC project, and the C++ run time. It works properly when run from the main console, but when run over a Terminal Server session on a Windows XP target, the install fails in the following way -
When the Setup.exe is invoked, it immediately crashes before the first welcome screen is displayed. When invoked over a physical console, the setup runs normally.
I figured I could go back to a lab machine to debug, but it runs fine on a lab machine over Terminal Server.
I see other descriptions of setup problems over Terminal Server sessions, but I don't see a definite solution. Both machines have a nearly identical configuration except that the one that is failing also has the GoToMyPC Host installed.
Has anyone else seen these problems, and how can I troubleshoot this?
Thanks,
I had LOTS of issues with developing installers (and software in general) for terminal server. I hate that damn thing.
Anyway, VS Setup Projects are just .msi files, and run using the Windows installer framework.
This will drop a log file when it errors out, they're called MSIc183.LOG (swap the c183 for some random numbers and letters), and they go in your logged-in-user account's temp directory.
The easiest way to find that is to type %TEMP% into the windows explorer address bar - once you're there have a look for these log files, they might give you a clue.
Note - Under terminal server, sometimes the logs don't go directly into %TEMP%, but under numbered subdirectories. If you can't find any MSIXYZ.LOG files in there, look for directories called 1, 2, and so on, and look in those.
If you find a log file, but can't get any clues from it, post it here. I've looked at more than I care to thing about, so I may be able to help
Before installing, drop to a command prompt and type
CHANGE USER /INSTALL
Then install your software. Once the install has completed, drop back to the command prompt and type:
CHANGE USER /EXECUTE
Alternatively, don't start the installation by a double click but instead go to Add/Remove Programs and select "install software" from there.
Good luck!