im tyring to get this to work:
#define UNICODE
#define _UNICODE
#include <wchar.h>
int main()
{
wprintf(L"Hello World!\n");
wprintf(L"£안, 蠀, ☃!\n");
return 0;
}
using visual studio 2008 express (on windows xp, if it matters).
when i run this from the command prompt (started as cmd /u which is supposed to enable unicode ?) i get this:
C:\dev\unicodevs\unicodevs\Debug>unicodevs.exe
Hello World!
┬ú∞
C:\dev\unicodevs\unicodevs\Debug>
which i suppose was to be expected given that the terminal does not have the font to render those.
but what gets me is that even if i try this:
C:\dev\unicodevs\unicodevs\Debug>cmd /u /c "unicodevs.exe > output.txt"
the file produced (even though its UTF-8 encoded) looks like:
Hello World!
壓
the source file itself is defined as unicode (encoded in UTF-8 without BOM).
the compiler output when building:
1>------ Rebuild All started: Project: unicodevs, Configuration: Debug Win32 ------
1>Deleting intermediate and output files for project 'unicodevs', configuration 'Debug|Win32'
1>Compiling...
1>main.c
1>.\main.c(1) : warning C4005: 'UNICODE' : macro redefinition
1> command-line arguments : see previous definition of 'UNICODE'
1>.\main.c(2) : warning C4005: '_UNICODE' : macro redefinition
1> command-line arguments : see previous definition of '_UNICODE'
1>Note: including file: C:\Program Files\Microsoft Visual Studio 9.0\VC\include\wchar.h
1>Note: including file: C:\Program Files\Microsoft Visual Studio 9.0\VC\include\crtdefs.h
1>Note: including file: C:\Program Files\Microsoft Visual Studio 9.0\VC\include\sal.h
1>C:\Program Files\Microsoft Visual Studio 9.0\VC\include\sal.h(108) : warning C4001: nonstandard extension 'single line comment' was used
1>Note: including file: C:\Program Files\Microsoft Visual Studio 9.0\VC\include\crtassem.h
1>Note: including file: C:\Program Files\Microsoft Visual Studio 9.0\VC\include\vadefs.h
1>Note: including file: C:\Program Files\Microsoft Visual Studio 9.0\VC\include\swprintf.inl
1>Note: including file: C:\Program Files\Microsoft Visual Studio 9.0\VC\include\wtime.inl
1>Linking...
1>Embedding manifest...
1>Creating browse information file...
1>Microsoft Browse Information Maintenance Utility Version 9.00.30729
1>Copyright (C) Microsoft Corporation. All rights reserved.
1>Build log was saved at "file://c:\dev\unicodevs\unicodevs\unicodevs\Debug\BuildLog.htm"
1>unicodevs - 0 error(s), 3 warning(s)
========== Rebuild All: 1 succeeded, 0 failed, 0 skipped ==========
any ideas on what am i doing wrong ?
similar questions on ST (like this one: unicode hello world for C?) seem to refer to *nix builds - as far as i understand setlocale() is not available for windows.
i also tried building this using code::blocks/mingw gcc, but got the same results.
It's not the writing (wprintf) that's the problem, it's the cmd redirection of output that's causing the problem. You can try testing by writing directly to file instead. In that case, you might then run into notepad (or rather Windows API function) not guessing correctly and interpreting your text as ASCII incorrectly if you're just writing a couple of words. In which case, you'll need to write the BOM characters into the file first as well.
#include <stdio.h>
#include <wchar.h>
int main()
{
FILE *out;
char bom[] = "\xFF\xFE";
wchar_t s[] = L"中文!";
size_t c;
out = fopen ("out.txt", "w");
if(out == NULL)
{
perror("out.txt");
return 1;
}
c = fwrite(bom, 1, 2, out);
if(c != 2)
{
perror ("Fatal write error.");
fclose(out);
return 2;
}
c = fwrite(s, sizeof(wchar_t), wcslen(s), out);
if(c != wcslen(s))
{
perror ("Fatal write error.");
fclose(out);
return 2;
}
fclose(out);
return 0;
}
Related
I am looking for how to install quickmail.
I put quickmail.h here: C:\Program Files\CodeBlocks\MinGW\include, the .a and .la here: C:\Program Files\CodeBlocks\MinGW\lib.
I linked these .a files by adding them in the linker settings. I also did include the library like this: #include <quickmail.h>, but the functions are not recognized.
What should I do ?
The 4 files in the bin folder are in the project folder and I downloaded files from here : quickmail - Sourceforge.
EDIT : I get \main.c|9|undefined reference to '__imp_quickmail_initialize'| \main.c|10|undefined reference to '__imp_quickmail_create'| \main.c|11|undefined reference to '__imp_quickmail_set_body' and I put C:\Program Files\CodeBlocks\MinGW\include in search directories.
This is the code :
#include <stdio.h>
#include <stdlib.h>
#include <quickmail.h>
int main()
{
const char* error;
quickmail_initialize();
quickmail mailobj = quickmail_create("aaa#gmail.com", "libquickmail test e-mail");
quickmail_set_body(mailobj, "This is a test e-mail.\nThis mail was sent using libquickmail.");
quickmail_add_attachment_file(mailobj, "words.txt", NULL);
if ((error = quickmail_send(mailobj, "smtp.gmail.com", 587, "aaa#gmail.com", "MAGA2020")) != NULL)
fprintf(stderr, "Error sending e-mail: %s\n", error);
quickmail_destroy(mailobj);
return 0;
}
Sorry, the site gave me the wrong version.
To use a library you need to include the header in the code (in this case #include <quickmail.h>) and if needed tell the compiler where to find this file (the full path to the lib folder) with the -I compiler flag.
Next you need to tell the linker to link with the library (in this case -lquickmail or -lquickmaillight) and if needed where to find this file (the full path to the lib folder) with the -L linker flag.
Your errors are linker errors, so it seems the second step wasn't properly done.
In Code::Blocks it looks like this (though unlike the screenshots you should set it at the top-level instead of just for Debug builds):
I am trying to compile a C file to use in Python. The file is a solver for differential algebric equations (DAE). My problem is that when I compile the setup.py file I receive the erro Cannot open source file: 'daesolver.c': No such file or directory. As the C file is quite complex I tried to do the same thing with a simpler example. I used the HelloWorld example provide by Elliot Forbes in (https://tutorialedge.net/python/python-c-extensions-tutorial/). Even in with this very simple function I receive the same error.
Here is the full output I receive from the build command.
C:\Users\Administrator>python c:\temp\teste_C2py\setup.py build
running build
running build_ext
building 'myModule' extension
C:\Program Files (x86)\Microsoft Visual
Studio\2017\Community\VC\Tools\MSVC\14.16.27023\bin\HostX86\x64\cl.exe /c
/nolog
o /Ox /W3 /GL /DNDEBUG /MD -IC:\ProgramData\Anaconda3\include -
IC:\ProgramData\Anaconda3\include "-IC:\Program Files (x8
6)\Microsoft Visual
Studio\2017\Community\VC\Tools\MSVC\14.16.27023\ATLMFC\include" "-
IC:\Program Files (x86)\Microsoft
Visual Studio\2017\Community\VC\Tools\MSVC\14.16.27023\include" "-
IC:\Program Files (x86)\Windows Kits\10\include\10.0.1
7763.0\ucrt" "-IC:\Program Files (x86)\Windows
Kits\10\include\10.0.17763.0\shared" "-IC:\Program Files (x86)\Windows Ki
ts\10\include\10.0.17763.0\um" "-IC:\Program Files (x86)\Windows
Kits\10\include\10.0.17763.0\winrt" "-IC:\Program Files
(x86)\Windows Kits\10\include\10.0.17763.0\cppwinrt" /Tctest.c
/Fobuild\temp.win-amd64-3.7\Release\test.obj
test.c
c1: fatal error C1083: Cannot open source file: 'test.c': No such file or
directory
error: command 'C:\\Program Files (x86)\\Microsoft Visual
Studio\\2017\\Community\\VC\\Tools\\MSVC\\14.16.27023\\bin\\Ho
stX86\\x64\\cl.exe' failed with exit status 2
Here is the test.c file
#include <Python.h>
// Function 1: A simple 'hello world' function
static PyObject* helloworld(PyObject* self, PyObject* args)
{
printf("Hello World\n");
return Py_None;
}
// Our Module's Function Definition struct
// We require this `NULL` to signal the end of our method
// definition
static PyMethodDef myMethods[] = {
{ "helloworld", helloworld, METH_NOARGS, "Prints Hello World" },
{ NULL, NULL, 0, NULL }
};
// Our Module Definition struct
static struct PyModuleDef myModule = {
PyModuleDef_HEAD_INIT,
"myModule",
"Test Module",
-1,
myMethods
};
// Initializes our module using our above struct
PyMODINIT_FUNC PyInit_myModule(void)
{
return PyModule_Create(&myModule);
}
and here is the setup.py
from distutils.core import setup, Extension
setup(name = 'myModule', version = '1.0', \
ext_modules = [Extension('myModule', ['test.c'])])
both files are located in the same folder c:\temp\teste_C2py.
I am using Python 3.7 in the Anaconda distribution 64 bits (I also want to do the same for x86).
I have installed in the same environment Visual Studio 2017 (community) with all the compiler for necessary (at least I think so).
The thing that is really strange is that I was made to do that when I installed just vs build tools 2017 in a VM but when I try to replicate the same in another machine it give me this error.
I also mess up the environment where I first made this work and now I am not able to do that again.
I also set up the environment variables VS150COMNTOOLS = C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\Common7\Tools
It seems that I am missing somenthing in the Visual Studio configuration because it does not make sense to no find a file that is the same folder.
I found the problem. As it used to be it was a very silly thing. I was trying do run the the setup script from the folder where the python.exe is located (because I have different versions of Python in my machine). But if instead of this I move to the folder where the setup.py file is located and run the coomand without any path befere the setup.py the build works! I don't have any idea why a relative path doesn't work here.
I hope this can help!
I have a Java program which makes use of some native function calls to speed up video encoding. It requires a DLL, which I will write in C (I have just a test one right now).
When I compile the DLL with cl /I "java-path/include" /"java-path/include/win32" -DL -ML Main.c -FeTest.dll it compiles, but I get a 32-bit DLL. After I did some research on the internet, I found out that I would need a 64-bit DLL instead.
After more research, I have found this post which is the only one for C (even C++ was hard to find), but this only works if you are writing/building via Visual Studio 2010. I am using Elipse for the Java, CLion for the C, and compiling via the "Developer Command Prompt." so this does not work for me. How might I recompile as a 64-bit DLL?
EDIT: I am using the cl.exe that comes with Visual Studio 2017
UPDATE: I found the 64-bit cl.exe under C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\VC\Tools\MSVC\14.13.26128\bin\Hostx64\x64\cl.exe, however when running it, I get an error that the library machine type (x86) conflicts with the target type (x64). How do I change the library machine type?
As I explained at the beginning of [SO]: How to build a DLL version of libjpeg 9b? (#CristiFati's answer) (bullets from 1. Prepare the ground section), there are different ways to deal with building from command line in VStudio. I'm going to focus on vcvarsall.bat. More details on [MSDN]: Setting the Path and Environment Variables for Command-Line Builds (It's VStudio2015 as VStudio2017 link is broken). I prepared a dummy example.
code.c:
#include <stdio.h>
#include "jni.h"
__declspec(dllexport) int func() {
JavaVMInitArgs args;
printf("Pointer size: %lld bits\n", sizeof(void*) * 8);
printf("JNI_GetDefaultJavaVMInitArgs returned: %d\n", JNI_GetDefaultJavaVMInitArgs(&args));
return 0;
}
Build:
e:\Work\Dev\StackOverflow\q050164687>"c:\Install\x86\Microsoft\Visual Studio Community\2017\VC\Auxiliary\Build\vcvarsall.bat" amd64
**********************************************************************
** Visual Studio 2017 Developer Command Prompt v15.6.6
** Copyright (c) 2017 Microsoft Corporation
**********************************************************************
[vcvarsall.bat] Environment initialized for: 'x64'
e:\Work\Dev\StackOverflow\q050164687>dir /b
code.c
e:\Work\Dev\StackOverflow\q050164687>cl /nologo /LD /I"c:\Install\x64\Oracle\Java\jdk1.8.0_152\include" /I"c:\Install\x64\Oracle\Java\jdk1.8.0_152\include\win32" /DWIN64 /DWIN32 code.c /link /LIBPATH:"c:\Install\x64\Oracle\Java\jdk1.8.0_152\lib" /OUT:dummy.dll jvm.lib
code.c
Creating library code.lib and object code.exp
e:\Work\Dev\StackOverflow\q050164687>dir /b
code.c
code.exp
code.lib
code.obj
dummy.dll
Notes:
My vcvarsall path is custom, because I installed VStudio2017 under "C:\Install\x86\Microsoft\Visual Studio Community\2017". Default path is "%SystemDrive%\Program Files (x86)\Microsoft Visual Studio\2017\Community"
After running vcvarsall, I don't have to specify to cl.exe (or link.exe):
The full path
Build options (architecture specific, including paths)
I still have to specify things that it doesn't know about (like Java stuff)
In order to test the newly built .dll, I'm going to use Python, as it's easier than writing another .c program that uses it
Since I linked the .dll to jvm.lib, at runtime it will need jvm.dll, so I'm adding its path into %PATH%
I built my code with VStudio2017 (VCRuntime14.0), but jvm.dll is linked to VCRuntime10.0 (VStudio2010), meaning that there will be (at least) 2 VCRuntimes loaded in my program. That is to be avoided as it could lead to all kinds of nasty problems
e:\Work\Dev\StackOverflow\q050164687>set PATH=%PATH%;c:\Install\x64\Oracle\Java\jdk1.8.0_152\jre\bin\server
e:\Work\Dev\StackOverflow\q050164687>"e:\Work\Dev\VEnvs\py35x64_test\Scripts\python.exe"
Python 3.5.4 (v3.5.4:3f56838, Aug 8 2017, 02:17:05) [MSC v.1900 64 bit (AMD64)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import ctypes
>>> dummy = ctypes.CDLL("dummy.dll")
>>> dummy.func()
Pointer size: 64 bits
JNI_GetDefaultJavaVMInitArgs returned: -1
0
>>>
When including a Linux header file, ucontext.h in this case, in a Linux C++ Project on Visual Studio 2017 for my C program, it does not recognize the header file. Even when I include sys/ucontext.h, it does not recognize functions that I should be able to use for a ucontext_t object, such as getContext() and setContext(). Shouldn't I be able to use these functions in a Linux C++ project?
Code I'm writing:
#include <stddef.h>
#include <string.h>
#include <sys/ucontext.h>
// If I use ucontext.h instead, it gives the error: cannot open source file ucontext.h
//TCB structure
typedef struct TCB_t {
struct TCB_t *next;
struct TCB_t *prev;
ucontext_t context;
} TCB_t;
void init_TCB(TCB_t *tcb, void *function, void *stackP, int stack_size)
{
memset(tcb, '\0', sizeof(TCB_t));
tcb->context.uc_stack.ss_sp = stackP;
tcb->context.uc_stack.ss_size = (size_t)stack_size;
int c = getcontext(tcb->context); // Cannot resolve field getcontext()
}
On this answer to do the following you need Visual Studio Community 2017 15.9.7+ - Tested this solution on Visual Studio Enterprise
2019 Preview 4.
Visual Studio needs to download all remote headers in your localmachine for correct behavior of intellisense.
New method 'rsync_ssh' doesn't download all headers. You can use old method .zip via sftp_ssh.
0. Add remote connection.
Tools->Options->Cross Platform->Connection Manager
1. Select your connection
Update from Tools->Options->Cross Platform->Connection Manager->Remote Headers Intellisense Manager.
Next click on Explore button.
2. C:\Users[YourUser]\AppData\Local\Microsoft\Linux\HeaderCache\1.0[IdNumber]
Rename the HeaderCache settings.xml.unused file to settings.xml
3. In the settings.xml file Change the syncMethod to sftp_ssh.
4. Update headers cache from Tools->Options->Cross Platform->Connection Manager->Remote Headers Intellisense Manager.
5. Enjoy.
Before
After
On my Linux system (Debian Jessie) ucontext.h is in usr/include which in turn includes sys/ucontext.h which gcc will find in usr/include/i386-linux-gnu/sys. The first defines the functions getcontext and setcontext. The second defines the data structures ucontext_t etc.
On the Windows host, VCLinux has installed a copy of the second ucontext.h (which defines the data structures) in C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\Linux\include\usr\include\x86_64-linux-gnu\sys . But the first ucontext.h is not present.
VCLinux/Visual Studio will compile and run this program on the Linux remote:
#include <ucontext.h>
#include <iostream>
int main()
{
ucontext ucxt;
::getcontext (&ucxt);
std::cout << ucxt.uc_flags << std::endl;
return 0;
}
But IntelliSense will not know about the functions getcontext and setcontext or the associated data structures. So you will get little red squiggles under the names and no completion assistance.
You can take a copy of the first ucontext.h and put it in C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\Linux\include\usr\include on your Windows host. Then everything will work as it should. And you could raise an issue for the missing header on the VCLinux GitHub site.
Note: Windows paths are for Visual Studio 2015. They will be different for 2017.
Applies to VCLinux 1.0.6.
==============
Update 10-Apr-18
Microsoft have addressed the issue of differences in standard include file locations between Linux systems. As explained in this Visual C++ blog post, the headers specific to the GCC setup are copied from the Linux remote and stored on the Windows host on a per-connection basis.
I've been trying to learn C, and I'm stuck on including libraries. I need to use strcpy(), but that method is included in the iostream library, but whenever I try to include the library, the program gives me errors. I've tried using "iostream", "iostream.h", , , but it either gives me a "can't find iostream.h" error, or the program exceeds 100 errors and just crashes. Even if my code is empty, I still get the same thing. Here's the code:
#include "iostream"
int main(void)
{
}
Yup, just that much makes it crash already. And here's a part of the errors I'm getting (could never paste them all here):
1>c:\program files (x86)\microsoft visual studio 10.0\vc\include\cmath(37): error C2061: syntax error : identifier 'abs'
1>c:\program files (x86)\microsoft visual studio 10.0\vc\include\cmath(37): error C2059: syntax error : ';'
1>c:\program files (x86)\microsoft visual studio 10.0\vc\include\cmath(39): error C2061: syntax error : identifier 'acos'
1>c:\program files (x86)\microsoft visual studio 10.0\vc\include\cmath(39): error C2059: syntax error : ';'
1>c:\program files (x86)\microsoft visual studio 10.0\vc\include\cmath(39): error C2061: syntax error : identifier 'asin'
1>c:\program files (x86)\microsoft visual studio 10.0\vc\include\cmath(39): error C2059: syntax error : ';'
1>c:\program files (x86)\microsoft visual studio 10.0\vc\include\cmath(40): error C2061: syntax error : identifier 'atan'
1>c:\program files (x86)\microsoft visual studio 10.0\vc\include\cmath(40): error C2059: syntax error : ';'
1>c:\program files (x86)\microsoft visual studio 10.0\vc\include\cmath(40): error C2061: syntax error : identifier 'atan2'
1>c:\program files (x86)\microsoft visual studio 10.0\vc\include\cmath(40): error C2059: syntax error : ';'
1>c:\program files (x86)\microsoft visual studio 10.0\vc\include\cmath(40): error C2061: syntax error : identifier 'ceil'
1>c:\program files (x86)\microsoft visual studio 10.0\vc\include\cmath(40): error C2059: syntax error : ';'
1>c:\program files (x86)\microsoft visual studio 10.0\vc\include\cmath(41): error C2061: syntax error : identifier 'cos'
1>c:\program files (x86)\microsoft visual studio 10.0\vc\include\cmath(41): fatal error C1003: error count exceeds 100; stopping compilation
========== Build: 0 succeeded, 1 failed, 0 up-to-date, 0 skipped ==========
So yeah it even exceeds the 100 errors and the program just stops counting. I don't understand why, I'm just including a regular library. Is there an equivalent of strcpy()? I mainly wanted to use it like this (for practice):
#include "stdafx.h"
#include "stdlib.h"
#include "stdio.h"
#include "conio.h"
#include "iostream"
int main(void)
{
struct person
{
int id;
char name[50];
int age;
};
struct person p1;
p1.id = 5595;
strcpy(p1.name, "Myname");
p1.age = 18;
printf("%d%s%d", p1.id, p1.name, p1.age);
}
<iostream> is a C++ header (it deals with input/ouput streams, as the name implies). If you want strcpy, you need <string.h>.
If your source file is ".c", all you have to do is to rename it ".cpp".
Then it'll compile as C++, you'll have the C++ headers, and you'll be able to use C++ streams.
I don't see any need for iostreams, however.
Strcpy and friends are in "<string.h>". Just include it, and "stdio.h" (like you're doing); delete the "iostreams" #include ... and life should be good.
iostreams are a C++-only feature. The iostreams header file is written in C++, not C. (Yes, they are different languages!) Presumably, you're invoking the compiler in C mode, so when the compiler looks at the header file it of course throws lots of errors since many of the constructs used in iostream makes sense only in C++ mode.
If you want to use iostreams, you have to compile in C++ mode (and code in proper, modern C++ accordingly), use a different library that's C-only or work around it by implementing your own code as necessary.
In this case, all you apparently want to do is to use strcpy(). That is declared in the string.h, not iostream. (string.h is a C header file.) Just #include <string.h> and it should compile.