implemented getprogname() for Windows #367

dplanitzer · 2018-06-19T22:36:07Z

We use GetModuleFileName() to get the filename of the process. InitOnceExecuteOnce() is used to do this once per app run.

dplanitzer · 2018-06-19T22:36:18Z

cc @MadCoder @compnerd

MadCoder · 2018-06-20T01:20:42Z

src/shims/getprogname.c

+                                            PVOID *lpContext);
+
+char *
+getprogname_win32(void)


move below to aovid having to do a forward.

pleas fix indent, and this function should be called getprogname

should also return const char *

MadCoder · 2018-06-20T01:21:33Z

src/shims/getprogname.h

@@ -30,13 +30,19 @@
 extern const char *__progname;
 #endif /* __ANDROID */

+#if defined(_WIN32)
+char* getprogname_win32(void);


char *getprogname_win32

MadCoder · 2018-06-20T01:22:39Z

src/shims/getprogname.c

+    return progname;
+}
+
+static BOOL CALLBACK getprogname_init_once_handler(


this should be written (with tabs indent):

static BOOL CALLBACK getprogname_init_once_handler(PINIT_ONCE InitOnce, PVOID Parameter, PVOID *lpContext) { ...

MadCoder · 2018-06-20T01:23:12Z

src/shims/getprogname.c

+        progname[0] = '\0';
+        return TRUE;
+    } else {
+        char * filename;


const char *filename;

compnerd · 2018-06-20T04:15:12Z

I thought that libbsd has an implementation of this function. Can we not just use that?

adierking · 2018-06-20T07:31:01Z

I thought that libbsd has an implementation of this function.

Not for Windows :(

dplanitzer · 2018-06-20T17:07:12Z

The lack of an actually functioning getprogname() implementation In libbsd on Windows is one problem that I see with the libbsd solution. But there are additional problems:

I've identified 3 major road blocks to making libdispatch work on Windows:

a) missing getprogname() implementation

b) missing TAILQ macros

c) missing event backend implementation

libbsd doesn't help with (a) and (c) because it doesn't come with a working getprogname(), kevent nor epoll implementation for Windows. It would only help to solve issue (b). Except that issue (b) is trivial enough to solve in the context of libdispatch itself.

The general problem that I see with adding 3rd party dependencies to Swift in the context of Windows is that:

Windows doesn't come with a package manager, making installation of 3rd party libs less convenient and more time consuming compared to Linux.
A 3rd party dependency may have a compiling, working and tested implementation for POSIX but not necessarily for Windows, forcing someone to sit down and make things work on Windows.
Windows users are not used to the idea that they would have to use a package manager to satisfy dependencies for an application before they will be able to run the app. They are used to downloading an installer that takes care of everything.
Every 3rd party dependency that Swift requires increases the minimum download size of an app that was built with Swift. But the goal should be to keep this minimum runtime size as small as possible.

So I would vastly prefer that libdispatch would just provide its own implementation of the necessary getprogname() and TAILQ macros instead of dragging libbsd in just for that.

dplanitzer · 2018-06-20T17:39:50Z

@MadCoder updated patch

MadCoder

only some minor spacing remarks, will merge

MadCoder · 2018-06-20T17:48:17Z

src/shims/getprogname.c

+		progname[0] = '\0';
+		return TRUE;
+	} else {
+		const char * filename;


remove the space after the star

MadCoder · 2018-06-20T17:48:57Z

src/shims/getprogname.c

+getprogname(void)
+{
+	(void) InitOnceExecuteOnce(&getprogname_init_once,
+				getprogname_init_once_handler,


these should be 2 indents from the base line, and remove the space after the cast.

MadCoder · 2018-06-20T17:49:23Z

src/shims/getprogname.h

@@ -30,6 +30,10 @@
 extern const char *__progname;
 #endif /* __ANDROID */

+#if defined(_WIN32)
+const char* getprogname(void);


const char *progname (mind the spaces)

dplanitzer · 2018-06-20T17:58:07Z

cc @MadCoder fixed spacing

MadCoder · 2018-06-20T18:27:50Z

@swift-ci please test

implemented getprogname() for Windows Signed-off-by: Kim Topley <ktopley@apple.com>

MadCoder suggested changes Jun 20, 2018

View reviewed changes

MadCoder added the changes requested label Jun 20, 2018

dplanitzer mentioned this pull request Jun 20, 2018

added a sys/queue.h implementation for Windows #368

Merged

MadCoder suggested changes Jun 20, 2018

View reviewed changes

implemented getprogname() for Windows

6a135fe

MadCoder approved these changes Jun 23, 2018

View reviewed changes

MadCoder removed the changes requested label Jun 23, 2018

MadCoder merged commit 82342ee into swiftlang:master Jun 23, 2018

MadCoder added the darwin pending label Jun 23, 2018

dplanitzer deleted the getprogname_for_windows branch June 27, 2018 21:46

ktopley-apple pushed a commit that referenced this pull request Dec 6, 2018

Merge pull request #367 from dplanitzer/getprogname_for_windows

dcbcc28

implemented getprogname() for Windows Signed-off-by: Kim Topley <ktopley@apple.com>

ktopley-apple removed the darwin pending label Apr 5, 2019

implemented getprogname() for Windows #367

implemented getprogname() for Windows #367

Uh oh!

Conversation

dplanitzer commented Jun 19, 2018

Uh oh!

dplanitzer commented Jun 19, 2018

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

compnerd commented Jun 20, 2018

Uh oh!

adierking commented Jun 20, 2018

Uh oh!

dplanitzer commented Jun 20, 2018

Uh oh!

dplanitzer commented Jun 20, 2018

Uh oh!

MadCoder left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

dplanitzer commented Jun 20, 2018

Uh oh!

MadCoder commented Jun 20, 2018

Uh oh!

Uh oh!