vasm Get Current Work Directory (Windows expert needed)

[phx]

The last days I have implemented DWARF support in the portable vasm assembler, which theoretically allows you to do source level debugging with an appropriate debugger.

DWARF needs to specify the current work directory in the .debug_info Compilation Unit, to find all paths relative to it. Unfortunately there is no portable way to determine this path and I have to write such a function for different operation systems. I do easily manage that for Unix, AmigaOS, Atari, etc., but I have absolutely no experience with Windows!

Does anybody know what is the best equivalent to getcwd() on Windows. I g**gled a lot and am about to try the following:

char *get_workdir(void)
{
  static char buf[MAX_PATH];
  char *fileExt;

  GetFullPathName("",MAX_PATH,buf,&fileExt);
  return buf;
}

I cannot test the code, because I have no Windows development environment. I know there is also GetCurrentDirectory(), but I'm not sure if it returns the full path, including drive letter, and whether there may be any 16-bit characters in the path?

Anybody here with some Windows knowledge who could help?
At least it would be nice when it still compiles (I know there are a lot of people using vasm under Windows).

[Leffmann]

Both getcwd and Microsoft's recommended alternative _getcwd are available to VC. Not sure about MingW.

GetCurrentDirectoryA() returns a char* to the absolute path, gives the absolute path with drive-letter, and if the path can't be converted to Windows 1252 (or whatever it uses) I guess it returns zero, but it would be a good idea to make vbcc, vasm, and vlink unicode compatible

[plasmab]

Happy to help. You targeting any particular C/C++ toolchain?

[jotd]

https://msdn.microsoft.com/en-us/library/sf98bd4y.aspx

there's a wgetcwd() which takes wide chars as input.

[phx]

I guess most people will use some MSVC++ version to compile vasm and a few others maybe Cygwin? I have no statistics.

But it would be nice, of course, when I could just call an OS function, which always works, and doesn't depend on a specific linker-library/toolchain.

So GetCurrentDirectoryA() sounds great, when it always returns a normal ASCII string as full path including drive-letter. Can somebody write an example function with it, like I did in my first post, and test if it works? Does it need "#include <windows.h>" or more?

In my opinion Unicode support in vasm isn't worth the hassle. It would introduce some new dependencies to charset-conversion libraries, which is something I don't like at all. vasm, as the whole vbcc toolchain, should stay simple, portable ANSI-C, without dependencies.

[plasmab]

Originally Posted by phx

So GetCurrentDirectoryA() sounds great, when it always returns a normal ASCII string as full path including drive-letter. Can somebody write an example function with it, like I did in my first post, and test if it works? Does it need "#include <windows.h>" or more?

In my opinion Unicode support in vasm isn't worth the hassle. It would introduce some new dependencies to charset-conversion libraries, which is something I don't like at all. vasm, as the whole vbcc toolchain, should stay simple, portable ANSI-C, without dependencies.

In general with MSVC++ you just use GetCurrentDirectory() and the Wide vs ASCII version gets patched in at link time depending on what you define your application as being at build time. Its a slight gotcha that can cause you a headache when you try and link (I spent 10 years in windows C++ hell).

EDIT: the gotcha here is that if you accidentally define a local method as GetCurrentDirectory() you'll get an error that the linker cant find GetCurrentDirectoryA() ... which is pretty infuriating IMHO.

[alpine9000]

Don’t forget Windows paths don’t always have a drive letter.

[Leffmann]

Originally Posted by phx

Can somebody write an example function with it, like I did in my first post, and test if it works? Does it need "#include <windows.h>" or more?

#define WIN32_LEAN_AND_MEAN
#include <windows.h>

char* get_workdir(void) {
  static char dir[MAX_PATH];
  GetCurrentDirectoryA(MAX_PATH, dir);
  return dir;
}

Works like it should in XP and Windows 10. If it can't convert the characters in the path to the OEM character set, it replaces them with question marks.

[plasmab]

I'll happily beta test this stuff. I use vbcc and vasm as part of my toolchain for the TF cards. @phx you should have my email address in your inbox from my bug reports in the past.

[clenched]

I know first hand anything needing windows.h will cause these conflicts when building VASM. Swept under the rug since only a couple of functions were needed.

#include <windows.h>
#undef LITTLEENDIAN
#undef BIGENDIAN
#undef LOBYTE
#undef HIBYTE
#undef NEAR
#undef ABSOLUTE
#undef ERROR

It's not clear what is wrong with getcwd. Is it to find path a.exe was ran from or where a.exe lives on drive? MAXPATHLEN clashes somewhere when compiled into VASM.

#include <stdio.h>
#include <unistd.h>  /* getcwd */
#include <sys/param.h>  /* MAXPATHLEN */
#define MAX_PATH MAXPATHLEN
int main(void)
{
static char buf[MAX_PATH];
getcwd(buf, MAX_PATH);
printf("I'm here in the middle - %s",buf);
}
----------------------------------------------------
C:\MinGW>gcc phx.c

C:\MinGW>a.exe
I'm here in the middle - C:\MinGW
C:\MinGW>
c:\vasm>\mingw\a.exe
I'm here in the middle - c:\vasm
c:\vasm>

[phx]

Originally Posted by Leffmann

#define WIN32_LEAN_AND_MEAN
#include <windows.h>

char* get_workdir(void) {
  static char dir[MAX_PATH];
  GetCurrentDirectoryA(MAX_PATH, dir);
  return dir;
}

Great! I could only hope it was so easy. Now, when clenched could confirm that it works the same with MinGW/gcc, then I take it!

Originally Posted by plasmab

I'll happily beta test this stuff. I use vbcc and vasm as part of my toolchain for the TF cards.

Thanks. I have just committed an update, which should be available with tomorrow's (UTC) snapshot. For the moment I'm using _getcwd(), which the author of "Virtual Jaguar" (who is working on DWARF support in his debugger) has confirmed working, but I would like to replace it.

@phx you should have my email address in your inbox from my bug reports in the past.

Probably. Although you were most likely using your real name, which I don't remember, and not "plasmab" - so it's not that easy.

Originally Posted by clenched

I know first hand anything needing windows.h will cause these conflicts when building VASM.

Arrrgh! I just restructured the source, because Atari's tos.h also defines ERROR, but there is so much more!

@Leffmann: Can you confirm those conflicts? Or doesn't MSVC warn about it (which wouldn't surprise me)? Or maybe those are different windows.h, depending on the compiler used?

It's not clear what is wrong with getcwd.

It's from a linker-library and not an OS function, so I fear it is not portable between different Windows compilers (like _getcwd(), which works with MSVC).

Is it to find path a.exe was ran from or where a.exe lives on drive?

As the name implies, I want to find the current work directory, i.e. the current directory you are in, when starting the assembler. This absolute path is needed in the DWARF compilation unit, so a DWARF-consumer can find your sources for source-level debugging.

MAXPATHLEN clashes somewhere when compiled into VASM.

That's why I didn't include <sys/param.h> in my Unix-version of get_workdir(), but use the vasm MAXPATHLEN instead.

[clenched]

Originally Posted by phx

Great! I could only hope it was so easy. Now, when clenched could confirm that it works the same with MinGW/gcc, then I take it!

From latest snapshot before touching anything:
No Warns No Errors and Nobody left on base. No surprise here.

Paste Leffmann's code near top of vasm.c
Some of the warnings I used to get are gone. It's been a long time since a stock build was made.
Still produces exe.

 
In file included from vasm.h:24:0,
                 from vasm.c:15:
symbol.h:34:0: warning: "NEAR" redefined
 #define NEAR (1<<15)        /* may refer symbol with near addressing modes */
 ^
In file included from c:/mingw/include/windows.h:48:0,
                 from vasm.c:4:
c:/mingw/include/windef.h:36:0: note: this is the location of the previous definition
 #define NEAR
 ^
In file included from vasm.h:31:0,
                 from vasm.c:15:
error.h:21:0: warning: "ERROR" redefined
 #define ERROR       1
 ^
In file included from c:/mingw/include/windows.h:52:0,
                 from vasm.c:4:
c:/mingw/include/wingdi.h:313:0: note: this is the location of the previous definition
 #define ERROR 0
 ^
In file included from vasm.c:15:0:
vasm.h:120:0: warning: "ABSOLUTE" redefined
 #define ABSOLUTE 16
 ^
In file included from c:/mingw/include/windows.h:52:0,
                 from vasm.c:4:
c:/mingw/include/wingdi.h:821:0: note: this is the location of the previous definition
 #define ABSOLUTE 1
 ^

[Leffmann]

Originally Posted by phx

@Leffmann: Can you confirm those conflicts? Or doesn't MSVC warn about it (which wouldn't surprise me)? Or maybe those are different windows.h, depending on the compiler used?

It's the same with VC, NEAR, ERROR, and ABSOLUTE are already defined. But that stuff can just live in its own file somewhere, IMO that's the best solution when you have a few small system dependent bits in an otherwise fully portable project.

Also thinking about what alpine9000 said, and on a network you may have paths that are much longer than those in the local file system (MAX_PATH, 260 characters), better replace that with 1000 or something.

[phx]

Thanks all!
Yes, I should include as few as possible of the vasm headers into my new osdep.c.

Originally Posted by Leffmann

you may have paths that are much longer than those in the local file system (MAX_PATH, 260 characters), better replace that with 1000 or something.

Usually I take vasm's MAXPATHLEN, which is 1024.