headers
Tor Lillqvist | 1 Jan 2005 03:13
Picon
Picon
Favicon

Directory Parsing

Ome thing you definitely should take into consideration from the start
if you intend your code to be more than a "toy", is that on Windows,
the actual file names in the file systems are in Unicode. You *should*
use the wide character versions of the dirent functions. Using the
normal (system codepage) versions does mean that your code won't be
able to see all file names that can be present on a system, viz. file
names containing characters not in the system codepage. (For instance,
on a US or Western European machine, file names with Greek or Cyrillic
characters in them.)

Ignoring these issues might mean that the majority of the World will
ignore your software ;-)

(You can wrap the wide character dirent funtions and convert the
wchar_t strings back and forth into UTF-8 so that the rest of your
code only sees char strings on Windows, too.)

--tml

-------------------------------------------------------
The SF.Net email is sponsored by: Beat the post-holiday blues
Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek.
It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt
_______________________________________________
MinGW-users mailing list
MinGW-users@...

You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
(Continue reading)

Permalink | Reply | 4 comments |
headers
Greg Chicares | 1 Jan 2005 03:09
Picon

Re: Directory Parsing

On 2004-12-31 4:20 PM, Jason Benjamin wrote:

> I'm trying to delve into more complex C programming. 
> I want to know how to use io.h (linked to by dir.h)
> for functions such as findfirst and so on with the
> purpose of creating programs that can search for files
> or perhaps perform like ls/dir.

The source for gnu utilities like 'ls' might show how
to do that. Try a mirror like
   http://ftp.hol.gr/mirror/gnu/coreutils/
and see whether they compile for the msw platform out
of the box, for a compiler whose standard library
offers <dirent.h>. If they don't, then compare the
gnu sources to a windows ports such as MinGW MSYS
to see what needs to be changed.

> I have found a few
> examples that work.  One is Windows API, but I'm not
> trying to do this with Windows API.  The other uses
> dirent.h.

The <dirent.h> version may already be what you want.
Try the sample program at the bottom of this email;
it works on msw with MinGW gcc. Other compilers may
lack library support for the posix functions.

> I've heard that this sort of thing is very
> compiler/OS specific, so once I have this figured out
> for GCC, there shouldn't be anymore problems.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Tor Lillqvist | 1 Jan 2005 04:08
Picon
Picon
Favicon

Re: Directory Parsing

Paul Grenyer writes:
 > If you want cross-platform and you're prepared to go to C++ then I believe 
 > the boost (www.boost.org) file library will do what you want.

I find it a bit sad that something as new and designed-from-scratch
like boost doesn't use the wide-character API on Windows. I understand
that they don't want to provide a wide-character API for boost itself,
but they should IMHO internally use wide-character APIs and then
take/return UTF-8 in the boost API.

Hmm, of course, this then would mean that file names returned from
boost couldn't be passed to the standard "char" file open functions
(which on Windows take system codepage strings), and they would have
to provide wrappers for these, too. Oh well, maybe they did consider
this and chose to ignore the issue.

--tml

-------------------------------------------------------
The SF.Net email is sponsored by: Beat the post-holiday blues
Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek.
It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt
_______________________________________________
MinGW-users mailing list
MinGW-users@...

You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
(Continue reading)

Permalink | Reply | 9 comments |
headers
John Gaughan | 1 Jan 2005 06:10
Gravatar

Re: Directory Parsing

Tor Lillqvist wrote:
> Ome thing you definitely should take into consideration from the
> start if you intend your code to be more than a "toy", is that on
> Windows, the actual file names in the file systems are in Unicode.

I know Windows NT/2000/XP/etc use Unicode in the kernel, but I thought 
the file system was still ASCII.

Either way, I think the majority of files use the lower 7 bits of 
Unicode, which is ASCII anyway.

--

-- 
John Gaughan
http://www.johngaughan.net/
john@...

-------------------------------------------------------
The SF.Net email is sponsored by: Beat the post-holiday blues
Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek.
It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt
_______________________________________________
MinGW-users mailing list
MinGW-users@...

You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Permalink | Reply | 3 comments |
headers
Greg Chicares | 1 Jan 2005 14:42
Picon

Re: Directory Parsing

On 2004-12-31 10:08 PM, Tor Lillqvist wrote:
> 
> I find it a bit sad that something as new and designed-from-scratch
> like boost doesn't use the wide-character API on Windows. I understand
> that they don't want to provide a wide-character API for boost itself,
> but they should IMHO internally use wide-character APIs and then
> take/return UTF-8 in the boost API.
> 
> Hmm, of course, this then would mean that file names returned from
> boost couldn't be passed to the standard "char" file open functions
> (which on Windows take system codepage strings), and they would have
> to provide wrappers for these, too. Oh well, maybe they did consider
> this and chose to ignore the issue.

It was a deliberate choice to use 'char' names. See
   http://boost.org/libs/filesystem/doc/faq.htm
under the heading
   "Why aren't wide-character names supported? \
   Why not std::wstring or even a templated type?"

-------------------------------------------------------
The SF.Net email is sponsored by: Beat the post-holiday blues
Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek.
It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt
_______________________________________________
MinGW-users mailing list
MinGW-users@...

You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
(Continue reading)

Permalink | Reply | 7 comments |
headers
Tor Lillqvist | 1 Jan 2005 17:24
Picon
Picon
Favicon

Re: Directory Parsing

John Gaughan writes:
 > I know Windows NT/2000/XP/etc use Unicode in the kernel, but I thought 
 > the file system was still ASCII.

Certainly not. It is UTF-16. (NTFS, that is, not FAT*.)

 > Either way, I think the majority of files use the lower 7 bits of 
 > Unicode, which is ASCII anyway.

So what? Even if just a very small part of the files on the World's
Windows machines have file names that can't be expressed in the
machine's system codepage, is that a reason to ignore them, in a
library that is supposed (?) to be well-designed from scratch without
any backward compatibility baggage?

--tml

-------------------------------------------------------
The SF.Net email is sponsored by: Beat the post-holiday blues
Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek.
It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt
_______________________________________________
MinGW-users mailing list
MinGW-users@...

You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Permalink | Reply | 2 comments |
headers
Tor Lillqvist | 1 Jan 2005 17:41
Picon
Picon
Favicon

Re: Directory Parsing

Greg Chicares writes:
 > It was a deliberate choice to use 'char' names. See
 >    http://boost.org/libs/filesystem/doc/faq.htm
 > under the heading
 >    "Why aren't wide-character names supported? \
 >    Why not std::wstring or even a templated type?"

Sure, I read that, too. But even when using 'char' file names, on
Windows that could be UTF-8, and they would then convert to/from
UTF-16 in the implementation and use the wide character versions of
the Win32 API.

Currently the 'char' names they use on Windows are in the system
codepage (as is the names passed to/from the C library's "normal"
functions). Did anybody check whether the boost implementation handles
double-byte characters correctly? Remember that if you use "codepage"
names, at least the Japanese codepage 932 has double-byte characters
where the second byte is a backslash. I.e. doing stuff like
strchr(filename, '\\') when parsing pathnames is broken.

With UTF-8, there is no such problem, and you then get the additional
benefit that on all machines you can handle all characters, not just
those in the system codepage.

--tml

-------------------------------------------------------
The SF.Net email is sponsored by: Beat the post-holiday blues
Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek.
It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt
(Continue reading)

Permalink | Reply | 0 comments |
headers
Robb Bean | 1 Jan 2005 19:31
Picon

Re: Directory Parsing

Jason Benjamin schrieb:

>I'm trying to delve into more complex C programming.
>
Good luck ;-)

>I want to know how to use io.h (linked to by dir.h)
>for functions such as findfirst and so on with the
>purpose of creating programs that can search for files
>or perhaps perform like ls/dir.
>
Is there a special reason why you want to use io.h? What about 
opendir(), readdir() and so on in stdio.h or fstat()? AFAIK do they also 
work on Windows, only the stat family is different from unix.

>I have found a few examples that work. One is Windows API, but I'm not
>trying to do this with Windows API.
>
Good idea, since this might change in future (with dot crap) and is not 
portable.

>The other uses dirent.h.
>
Oh, that I meant above. Sorry for the typo (stdio.h).

>I've heard that this sort of thing is very compiler/OS specific, so once I have this figured out for GCC,
there shouldn't be anymore problems.  I am
>slightly confused on how to declare and deal with the struct involved.
>  
>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Bryce McKinlay | 1 Jan 2005 23:53
Picon
Favicon

Debugging mingw applications using wine

I'm trying to debug a windows .exe built with mingw using wine, but 
winedbg seems to have problems reading stabs from the mingw-built 
binary. My goal is to be able to debug a cross-compiled, native Java 
(GCJ) application, but even a simple C "hello world" seems to cause 
problems.

My cross-build environment consists of:

- mingw-runtime-3.5 and w32api-3.1from mingw.org - I just used the 
pre-built binaries
- stock binutils 2.15, configured with --target=mingw32
- CVS head gcc 4.0, configured with --target=mingw32

WINE is wine-0.20040914-1.rhfc2.nr from newrpms.sunsite.dk

$ mingw32-gcc hello.c -o hello-mingw.exe -g

$ wine ./hello-mingw.exe
Hello World

$ winedbg --gdb ./hello-mingw.exe
0000000a:0000000b: create process 'D:\tests\hello-mingw.exe'/0x77bd003c 
 <at> 00401220 (0<0>)
wine: Unhandled exception (thread 0009), starting debugger...
WineDbg starting on pid 0x8
Unhandled exception: page fault on read access to 0xb6e4d174 in 32-bit 
code (0x657997a3).
In 32 bit mode.
Register dump:
 CS:0073 SS:007b DS:007b ES:007b FS:003b GS:0033
(Continue reading)

Permalink | Reply | 0 comments |
headers
Scott Ritchie | 2 Jan 2005 03:04
Gravatar

Re: Debugging mingw applications using wine


On Sat, 2005-01-01 at 17:53 -0500, Bryce McKinlay wrote:

> WINE is wine-0.20040914-1.rhfc2.nr from newrpms.sunsite.dk

Did you try the newer rpms on Wine's download page?  One was probably
built for the same setup you're using.

> I've attached the mingw-compiled C binary. Is it worth trying again with 
> a newwer WINE? Thanks!
> 

Always!

-Scott Ritchie
Permalink | Reply | 0 comments |

Gmane