English Amiga Board


Go Back   English Amiga Board > Coders > Coders. General

 
 
Thread Tools
Old 13 October 2018, 12:23   #1
phx
Natteravn

phx's Avatar
 
Join Date: Nov 2009
Location: Herford / Germany
Posts: 1,201
vasm Get Current Work Directory (Windows expert needed)

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:
Code:
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).
phx is offline  
Old 13 October 2018, 14:19   #2
Leffmann
 
Join Date: Jul 2008
Location: Sweden
Posts: 2,186
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
Leffmann is offline  
Old 13 October 2018, 17:53   #3
plasmab
Banned
plasmab's Avatar
 
Join Date: Sep 2016
Location: UK
Posts: 2,917
Happy to help. You targeting any particular C/C++ toolchain?
plasmab is offline  
Old 13 October 2018, 22:16   #4
jotd
Cat freak
jotd's Avatar
 
Join Date: Dec 2004
Location: FRANCE
Age: 47
Posts: 2,627
https://msdn.microsoft.com/en-us/library/sf98bd4y.aspx

there's a wgetcwd() which takes wide chars as input.
jotd is offline  
Old 14 October 2018, 02:43   #5
phx
Natteravn

phx's Avatar
 
Join Date: Nov 2009
Location: Herford / Germany
Posts: 1,201
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.
phx is offline  
Old 14 October 2018, 02:46   #6
plasmab
Banned
plasmab's Avatar
 
Join Date: Sep 2016
Location: UK
Posts: 2,917
Quote:
Originally Posted by phx View Post
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.
plasmab is offline  
Old 14 October 2018, 03:12   #7
alpine9000
Registered User

 
Join Date: Mar 2016
Location: Australia
Posts: 611
Don’t forget Windows paths don’t always have a drive letter.
alpine9000 is offline  
Old 14 October 2018, 12:11   #8
Leffmann
 
Join Date: Jul 2008
Location: Sweden
Posts: 2,186
Quote:
Originally Posted by phx View Post
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?
Code:
#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.
Leffmann is offline  
Old 14 October 2018, 12:25   #9
plasmab
Banned
plasmab's Avatar
 
Join Date: Sep 2016
Location: UK
Posts: 2,917
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.
plasmab is offline  
Old 14 October 2018, 12:28   #10
clenched
Registered User

 
Join Date: Sep 2008
Location: Gainesville U.S.A.
Posts: 639
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.

Code:
#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.

Code:
#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>
clenched is offline  
Old 14 October 2018, 15:09   #11
phx
Natteravn

phx's Avatar
 
Join Date: Nov 2009
Location: Herford / Germany
Posts: 1,201
Quote:
Originally Posted by Leffmann View Post
Code:
#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!

Quote:
Originally Posted by plasmab View Post
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.

Quote:
@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.

Quote:
Originally Posted by clenched View Post
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?

Quote:
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).

Quote:
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.

Quote:
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.
phx is offline  
Old 14 October 2018, 16:33   #12
clenched
Registered User

 
Join Date: Sep 2008
Location: Gainesville U.S.A.
Posts: 639
Quote:
Originally Posted by phx View Post
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.

Code:
 
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
 ^
clenched is offline  
Old 14 October 2018, 17:57   #13
Leffmann
 
Join Date: Jul 2008
Location: Sweden
Posts: 2,186
Quote:
Originally Posted by phx View Post
@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.

Last edited by Leffmann; 14 October 2018 at 18:07.
Leffmann is offline  
Old 15 October 2018, 21:57   #14
phx
Natteravn

phx's Avatar
 
Join Date: Nov 2009
Location: Herford / Germany
Posts: 1,201
Thanks all!
Yes, I should include as few as possible of the vasm headers into my new osdep.c.

Quote:
Originally Posted by Leffmann View Post
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.
phx is offline  
 


Currently Active Users Viewing This Thread: 1 (0 members and 1 guests)
 
Thread Tools

Similar Threads
Thread Thread Starter Forum Replies Last Post
Building VASM on Windows guy lateur Coders. Asm / Hardware 16 30 September 2018 17:57
Reading files from current directory in assembly hukka Coders. System 29 01 January 2018 23:03
Will WinUAE work in Windows 10? DisposableHero support.WinUAE 8 25 July 2015 22:16
Compress all adf's in a directory (Windows) Leandro Jardim Amiga scene 6 05 January 2012 04:08
Directory Opus (Windows) update Galaxy News 4 25 May 2004 21:55

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +2. The time now is 20:33.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2018, vBulletin Solutions Inc.
Page generated in 0.08266 seconds with 14 queries