Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Makefile.m32: add support for UNICODE builds #6228

Closed
wants to merge 1 commit into from

Conversation

vszakats
Copy link
Member

It requires the linker to support the -municode option.

It requires the linker to support the -municode option.
src/Makefile.m32 Show resolved Hide resolved
@jay jay added build Windows Windows-specific labels Nov 20, 2020
@emilengler
Copy link
Contributor

Just curious, isn't Unicode support a C11 thing or am I getting it wrong ehat is meant by this

@vtorri
Copy link
Contributor

vtorri commented Nov 20, 2020

@emilengler on Windows, the macro UNICODE is used to specify which API should be used, mainly when dealing with path names. But the name of the macro is misleading. It actually sets the character encoding used for path names : ANSI or UTF-16. These API exists at least since Windows XP. For example, when you call Createfile() API :

  • if UNICODE is defined, CreateFileW() is called
  • otherwise, it's CreateFileA()

@emilengler
Copy link
Contributor

Ok my mistake, thansk for the clarification 👌

@jay
Copy link
Member

jay commented Nov 20, 2020

Windows docs sometimes say Unicode but actually they mean a certain type of Unicode encoding, UTF-16.

Do we need -municode, what does it actually do? Use wmain entry? I thought that was detected automatically by the compiler (or at least that's how we have it set now):

curl/src/tool_main.c

Lines 273 to 281 in 315ee3f

/*
** curl tool main function.
*/
#ifdef _UNICODE
int wmain(int argc, wchar_t *argv[])
#else
int main(int argc, char *argv[])
#endif
{

@vtorri
Copy link
Contributor

vtorri commented Nov 20, 2020

@jay for -municode : https://gcc.gnu.org/onlinedocs/gcc/x86-Windows-Options.html

@vszakats
Copy link
Member Author

vszakats commented Nov 20, 2020

wmain() isn't the only solution; it's also possible to stay with main(), but in that case the command-line needs to be parsed manually after retrieving it via GetCommandLine() in UNICODE. Normally, Windows doesn't do a whole lot with the passed command-line, so parsing it is relatively straightforward. I'm not sure however what extra magic (globbing?) may be done by MinGW's *main() entry code – this is something to look at.

@vszakats vszakats closed this in 3e092ad Nov 23, 2020
@vszakats vszakats deleted the m32uni branch November 23, 2020 16:57
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
build Windows Windows-specific
Development

Successfully merging this pull request may close these issues.

None yet

5 participants