Windows doesn't support getopt

[nfc-tools]

Windows doesn't support getopt

[GoogleCodeExporter]

Hey Fkooman, 
Thanks for reporting. You're right Windows sucks, it doesn't support getopt. Do 
you
know some similar functions in Windows world ?

Original comment by [email protected] on 2 Sep 2009 at 3:55

• Added labels: Priority-High
• Removed labels: Priority-Medium

[GoogleCodeExporter]

Maybe this link can be helpful : 
http://note.sonots.com/EngNote/CompLang/cpp/getopt.html

Original comment by [email protected] on 2 Sep 2009 at 4:11

[GoogleCodeExporter]

Hey Fkooman,

I haven't any Windows platform here, could you try to fix it using previously 
given
link ? or with another way ?

Thanks a lot.

Original comment by [email protected] on 3 Sep 2009 at 3:30

[GoogleCodeExporter]

I was playing with this for a bit, but the getopt code you mentioned seems a bit
broken. I'll look into making something myself maybe, or using one of the other
available "replacements" like XGetopt
(http://www.codeproject.com/KB/cpp/xgetopt.aspx), but it seems to be in C++, 
bleh

Any thoughts on that? I guess it is possible to only use XGetopt on Windows and 
fall
back to getopt in Unix, I just hope non of the programs need to be changed...

Original comment by fkooman%[email protected] on 4 Sep 2009 at 9:40

[GoogleCodeExporter]

Hi,
Maybe the solution could be to handle command line option "by hands" like 
mftool (or
mfultool) does. Examples which are affected by this "bug" are: nfc-anticol,
nfc-emulate and nfc-relay. This "bug" have been introduce in r72.

What do you think about that, Fkooman ? (Roel? Adam? Anybody?)

Original comment by [email protected] on 4 Sep 2009 at 1:33

[GoogleCodeExporter]

To me that seems like a good idea. Although Roel is the only one actually using
Windows? :P We can also use a big #ifdef to not have any command line option 
stuff
available in Windows and just choose sensible defaults. 

Was -DDEBUG not meant for printing all this stuff? Maybe it makes sense to print
nothing (or only the absolute necessary) when -DDEBUG is not specified.

Original comment by fkooman%[email protected] on 4 Sep 2009 at 8:59

[GoogleCodeExporter]

> Roel is the only one actually using Windows?
AFAIK, Roel is more a OSX user than Windows one.. Windows support in libnfc is 
only
for users convenience (and developers headaches).

> We can also use a big #ifdef
I have wrote some lines that could works under Windows and standard POSIX 
systems. 

> Was -DDEBUG not meant for printing all this stuff?
No. -DDEBUG is for development debugging purpose. Here (anticol, emulate and 
relay)
use verbose output to be able to trace transmission, for hacking purpose for 
example.

Thanks for your help Fkooman, this issue is fixed in r99.

Original comment by [email protected] on 7 Sep 2009 at 10:21

• Changed state: Fixed

[GoogleCodeExporter]

Patch to:
- reenable the broken tools in Windows in cmake files
- add some more exports to bitutils to make compilation succeed.

I think you can consider removing everything from the win32 directory except the
stdint directory, unless a 64 bit Windows version is a current feature. This 
requires
some more work on the CMake files to find the correct library 32/64 bit 
libraries.

You also want to make a windows binary (installable) release in the future? That
should be no problem now with this CMake/MSVC/NSIS stuff.

Original comment by fkooman%[email protected] on 7 Sep 2009 at 10:58

Attachments:

• windows_reenable_apps.patch