I've got a very simple program which lists all .txt files in a given directory. This program has run perfectly on my Mac which has the Rakudo Star version 2019.03.1
use File::Find;
my $folder="../Documents";
.say for find dir => $folder, name => /'.txt' $/;
When I've tried to run the same program on Windows 7 which had Raku 2020.12.1 it gave this:
$ raku html-adder.rk
===SORRY!=== Error while compiling C:\Users\lars\raku/html-adder.rk
Could not find File::Find in:
inst#C:\Users\lars\.raku
inst#C:\Programs\rakudo-moar-2021.02.1\share\perl6\site
inst#C:\Programs\rakudo-moar-2021.02.1\share\perl6\vendor
inst#C:\Programs\rakudo-moar-2021.02.1\share\perl6\core
ap#
nqp#
perl5#
at C:\Users\lars\raku/html-adder.rk:12
I've updated the Raku to version Raku 2021.02.1 and the same error again. I've installed it by unzipping the rakudo-moar-2021.02.1-01-win-x86_64-msvc.zip i.e. without using any installer. And as regards to the Raku on Mac, I don't remember installing the File::Find module, nor do I know how to list the installed modules, i.e. I haven't checked if File::Find was installed on Mac or Windows 7.
How to make this program work on Windows 7?
File::Find is not built into Raku or distributed with Rakudo Star; to my knowledge, it never has been.
It is a module in the ecosystem that you can install with Zef (use the command zef install File::Find).
It is also a very short library. If you are interested in fixing your script without adding a dependency, you may want to check out the source code for File::Find; it is short enough that you could easily implement the same functionality yourself.
I've downloaded the source files for the TBB libraries, with the intent to build them and link them into my CMake project. The readme file says "type 'gmake' in this directory to build and test."
My question is - how do I run gmake on a Windows machine.
The solution in this answer didn't work for me. This is what I get:
From the log I see that make unable to find Microsoft compiler cl.exe. To fix this, you must use one of the "Visual Studio command prompt"-s, those are cmd with environments targeted to command-line tools.
If you use MigGW by chance, the command should be
make compiler=gcc.
In this case, path environment variable should contain path to MigGW.
I want to compile objective-c from eclipse with foundation.h support.
I can do it with GNUStep inside the MSYS shell, but I want to do it directly from eclipse Makefile without launching the Shell
is is possible?
As default XCode and a MAC machine is the right solution, But it will be great if atleast I can play with NSDictionary in a window machine before I really do in XCode
After checking the environment variables inside the GNUStep, I made the Objective-C code working directly with eclipse without launching the MSYS terminal
Download and install GNUStep from http://www.gnustep.org/windows/installer.html
Download and install Eclipse Luna for C/C++ https://eclipse.org/downloads/
After installation
You can launch GNUStep Shell and execute "set > paths.txt"
This paths.txt file will have all the related environment path with Unix directory structure
Convert all those paths to windows path structure and windows path delimiter ";"
You need to set few environment variables including GNUSTEP_MAKEFILES, LD_LIBRARY_PATH, GNUSTEP_PATHLIST, GNUSTEP_SYSTEM_ROOT, GNUSTEP_USER_ROOT, GNUSTEP_HOST, GNUSTEP_HOST_CPU, GNUSTEP_HOST_OS, LIBRARY_COMBO, WD, GNUSTEP_IS_FLATTENED, GNUSTEP_FLATTENED..... with absolute path locations using front slash (avoid back slashes)
Make sure you provide the TMP and TEMP folder paths as shown below
Create a C/C++ project in eclipse, You should name your makefile as GNUStepMakefile
As usual you can create the GNUMakefile with reference to GNUStep docs http://www.gnustep.it/nicola/Tutorials/WritingMakefiles/, introduce one extra target to execute the exe file
Now you can write your .m file
You have to add the .m file to the eclipse file types and default editor as C/C++ editor
Eclipse-Window-Show View->Other->Make->Make Target ........ introduce targets as all, clean, run
Double click "all" from the Make Target
Double click "run" from the Make Target
Now you can compile and run Objective-C without launching the GNUStep Shell
Note: you are only practising Objective-C with Foundation classes, you cannot create real IOS/MAC app here, for that you definitely need a MAC PC/Laptop
If you don't want to use Makefile and directly use CDT to compile the code you can use this Technique https://www.youtube.com/watch?v=JQ8aIe4p6ds
I have created a Command Line Utility C++ tool in XCode using Objective-C. I want the version number to be displayed in the Info of the created executable. So I have added the version number 1.0.0.0 in the Current Project Version field in the Build settings. However, when I build it, the version number does not get added to the created 'Unix Executable File'.
Am I missing something?
Thanks for the help.
Unfortunately, Xcode will not embed the current project version into the executable by itself, as of version 3. I'm not sure if this has changed in Xcode 4.
I ran into this problem a couple of years ago. It turns out that:
Version numbers displayed in the Finder come from applications’ Info.plists. In the case of an application bundle, Info.plist is a file. In the case of an executable, it must be embedded in a __TEXT section. The format of the Info.plist is the same either way.
Xcode does not have one-click support for embedding Info.plists into executables, but it is possible.
Xcode doesn’t preprocess Info.plist files unless they’re going into an application bundle (e.g. to insert the value of CURRENT_PROJECT_VERSION).
I hacked up a solution, but it’s unpolished and probably doesn’t represent best practices.
First, I created a new, stock Info.plist file called Info_template.plist. I set CFBundleVersion to ${CURRENT_PROJECT_VERSION}, and CFBundleShortVersionString to ${CURRENT_MARKETING_VERSION}.
Then, I added a Run Script phase called “Preprocess Info.plist” at the beginning of the build, using /bin/sh as the shell, with this script:
set -u
if ! [[ ${CURRENT_PROJECT_VERSION:-""} && ${CURRENT_MARKETING_VERSION:-""} ]]; then
echo "Version numbers are not set" >&2
exit 1
fi
# Ghetto environment variable expansion, since Xcode does not appear to have built-in expansion for arbitrary files
{ echo "cat <<EOF"
cat ${SRCROOT}/Info_template.plist
echo "EOF"
} | sh > ${DERIVED_FILES_DIR}/Info.plist
I added $(DERIVED_FILE_DIR)/Info.plist to its output files.
Then, I opened the target’s build settings, and added this to Other Linker Flags:
-sectcreate __TEXT __info_plist ${DERIVED_FILE_DIR}/Info.plist
This asks the linker to roll the generated Info.plist file into the executable.
Let me know how this works for you, or if I left anything out!
I have tried to use the following code:
cd c:\windows\system32
regsvr32.exe dllname.ax
But this is not working for me. How can I register a DLL file on Windows 7 with a 64-bit processor?
Well, you don't specify if it's a 32 or 64 bit dll and you don't include the error message, but I'll guess that it's the same issue as described in this KB article: Error Message When You Run Regsvr32.exe on 64-Bit Windows
Quote from that article:
This behavior occurs because the Regsvr32.exe file in the System32
folder is a 64-bit version. When you run Regsvr32 to register a DLL,
you are using the 64-bit version by default.
Solution from that article:
To resolve this issue, run Regsvr32.exe from the %SystemRoot%\Syswow64
folder. For example, type the following commands to register the DLL:
cd \windows\syswow64 regsvr32 c:\filename.dll
If the DLL is 32 bit:
Copy the DLL to C:\Windows\SysWoW64\
In an elevated command prompt: %windir%\SysWoW64\regsvr32.exe %windir%\SysWoW64\namedll.dll
if the DLL is 64 bit:
Copy the DLL to C:\Windows\System32\
In an elevated command prompt: %windir%\System32\regsvr32.exe %windir%\System32\namedll.dll
I know it seems the wrong way round, but that's the way it works. See:
http://support.microsoft.com/kb/249873
Quote: "Note On a 64-bit version of a Windows operating system, there are two versions of the Regsv32.exe file:
The 64-bit version is %systemroot%\System32\regsvr32.exe.
The 32-bit version is %systemroot%\SysWoW64\regsvr32.exe.
"
Type regsvr32 name.dll into the Command Prompt (executed in elevated mode!) and press "Enter." Note that name.dll should be replaced with the name of the DLL that you want to register. For example, if you want to register the iexplore.dll, type regsvr32 iexplore.dll.
On a x64 system, system32 is for 64 bit and syswow64 is for 32 bit (not the other way around as stated in another answer). WOW (Windows on Windows) is the 32 bit subsystem that runs under the 64 bit subsystem).
It's a mess in naming terms, and serves only to confuse, but that's the way it is.
Again ...
syswow64 is 32 bit, NOT 64 bit.
system32 is 64 bit, NOT 32 bit.
There is a regsrv32 in each of these directories. One is 64 bit, and the other is 32 bit.
It is the same deal with odbcad32 and et al. (If you want to see 32-bit ODBC drivers which won't show up with the default odbcad32 in system32 which is 64-bit.)
Open the start menu and type cmd into the search box Hold Ctrl + Shift and press Enter
This runs the Command Prompt in Administrator mode.
Now type: regsvr32 MyComobject.dll
If the DLL is 32 bit:
Copy the DLL to C:\Windows\SysWoW64\
In elevated cmd: %windir%\SysWoW64\regsvr32.exe %windir%\SysWoW64\namedll.dll
if the DLL is 64 bit:
Copy the DLL to C:\Windows\System32\
In elevated cmd: %windir%\System32\regsvr32.exe %windir%\System32\namedll.dll
Finally I found the solution just run CMD as administrator then write
cd \windows\syswow64
then write this
regsvr32 c:\filename.dll
I hope that answer will help you
Everything here was failing as wrong path. Then I remembered a trick from the old Win95 days. Open the program folder where the .dll resides, open C:/Windows/System32 scroll down to regsvr32 and drag and drop the dll from the program folder onto rgsrver32. Boom,done.
And while doing this, if you get error code 0x80040201, try the solution in DllRegisterServer failed with the error code 0x80040201, but make sure, you open command prompt as Run as Administrator.
Knowing the error message would be rather valuable. It is meant to provide info, even though it doesn't make any sense to you it does to us. Being forced to guess, I'd say that the DLL is a 32-bit DirectX filter. In which case this should be the proper course of action:
cd c:\windows\syswow64
move ..\system32\dllname.ax .
regsvr32.exe dllname.ax
This must be run at an elevated command prompt so that UAC cannot stop the registry access that's required. Ask more questions about this at superuser.com
I just tested this extremely simple method and it works perfectly--but I use the built-in Administrator account, so I don't have to jump through hoops for elevated privileges.
The following batch file relieves the user of the need to move files in/out of system folders. It also leaves it up to Windows to apply the proper version of Regsvr32.
INSTRUCTIONS:
In the folder that contains the library (-.dll or -.ax) file you wish to register, open a new text file and paste in ONE of the routines below :
echo BEGIN DRAG-AND-DROP %n1 REGISTRAR FOR 64-BIT SYSTEMS
copy %1 C:\Windows\System32
regsvr32 "%nx1"
echo END BATCH FILE
pause
echo BEGIN DRAG-AND-DROP %n1 REGISTRAR FOR 32-BIT SYSTEMS
copy %1 C:\Windows\SysWOW64
regsvr32 "%nx1"
echo END BATCH FILE
pause
Save your new text file as a batch (-.bat) file; then simply drag-and-drop your -.dll or -.ax file on top of the batch file.
If UAC doesn't give you the opportunity to run the batch file as an Administrator, you may need to manually elevate privileges (instructions are for Windows 7):
Right-click on the batch file;
Select Create shortcut;
Right-click on the shortcut;
Select Properties;
Click the Compatibility tab;
Check the box labeled Run this program as administrator;
Drag-and-drop your -.dll or -.ax file on top of the new shortcut instead of the batch file.
That's it. I chose COPY instead of MOVE to prevent the failure of any UAC-related follow-up attempt(s). Successful registration should be followed by deletion of the original library (-.dll or -.ax) file.
Don't worry about copies made to the system folder (C:\Windows\System32 or C:\Windows\SysWOW64) by previous passes--they will be overwritten every time you run the batch file.
Unless you ran the wrong batch file, in which case you will probably want to delete the copy made to the wrong system folder (C:\Windows\System32 or C:\Windows\SysWOW64) before running the proper batch file, ...or...
Help Windows choose the right library file to register by fully-qualifying its directory location.
From the right batch file copy the system folder path
If 64-bit: C:\Windows\System32
If 32-bit: C:\Windows\SysWOW64
Paste it on the next line so that it precedes %nx1
If 64-bit: regsvr32 "C:\Windows\System32\%nx1"
If 32-bit: regsvr32 "C:\Windows\SysWOW64\%nx1"
Paste path inside quotation marks
Insert backslash to separate %nx1 from system folder path
or ...
Run this shotgun batch file, which will (in order):
Perform cleanup of aborted registration processes
Reverse any registration process completed by your library file;
Delete any copies of your library file that have been saved to either system folder;
Pause to allow you to terminate the batch file at this point (and run another if you would like).
Attempt 64-Bit Installation on your library file
Copy your library file to C:\Windows\System32;
Register your library file as a 64-bit process;
Pause to allow you to terminate the batch file at this point.
Undo 64-Bit Installation
Reverse any registration of your library file as a 64-bit process;
Delete your library file from C:\Windows\System32;
Pause to allow you to terminate the batch file at this point (and run another if you would like).
Attempt 32-Bit Installation on your library file
Copy your library file to C:\Windows\SystemWOW64
Register your library file as a 32-bit process;
Pause to allow you to terminate the batch file at this point.
Delete original, unregistered copy of library file
There is a difference in Windows 7. Logging on as Administrator does not give the same rights as when running a program as Administrator.
Go to Start - All Programs - Accesories.
Right click on the Command window and select "Run as administrator"
Now register the dll normally via : regsrvr32 xxx.dll
You need run the cmd.exe in c:\windows\system32\ by administrator
Commands:
For unregistration *.dll files
regsvr32.exe /u C:\folder\folder\name.dll
For registration *.dll files
regsvr32.exe C:\folder\folder\name.dll
Part of the confusion regarding regsvr32 is that on 64-bit windows the name and path have not changed, but it now registers 64-bit DLLs. The 32-bit regsvr32 exists in SysWOW64, a name that appears to represent 64-bit applications. However the WOW64 in the name refers to Windows on Windows 64, or more explicity Windows 32-bit on Windows 64-bit. When you think of it this way the name makes sense even though it is confusing in this context.
I cannot find my original source on an MSDN blog but it is referenced in this Wikipedia article http://en.wikipedia.org/wiki/WoW64
Here is how I fixed this issue on a Win7 x64 machine:
1 - error message:
"CoCreateInstance() failed
Plkease check your registry entries
CLSID{F088EA74-2E87-11D3-B1F3-00C0F03C37D3} and make sure you are logged in as an administrator"
2 - fix procedure:
Start/type cmd/RightMouseClick on cmd.exe and choose to "Run as Administrator"
typed:
regsvr32 /s C:\Program Files\Autodesk\3ds Max Design 2015\atl.dll
regsvr32 /s C:\Program Files\Autodesk\3ds Max Design 2015\MAXComponents.dll
restart Win 7 and back in business again !
Hope this helps !