Parport build test

[ndim]

This came up during build tests: The parallel port code was not built during CI, and it failed compiling for Windows using the mingw64 or ucrt64 cross compile toolchains on Fedora Linux.

So this PR

• fixes the function prototypes for port_get() in ppiwin.c to allow compilation

• has all platforms on GitHub's CI infrastructure on which avrdude supports the parallel port test build with the parallel port code

It does not fix the fact that libavrdude uses a avrdude_message2() function which is defined in avrdude, which causes problems building for Windows. A library using a symbol from an executable while the same executable uses a symbol from the library appears to be difficult to impossible with Windows DLLs.

[stefanrueger]

Thanks for the PR!

problems building for Windows

How has this been built until now? Statically without DLL?

I have thought for some time that main.c isn't the best place for the messaging functions. Sounds like it's better to move them to a different place that could be compiled into a messaging library? That way someone can build their own all-singing/all-dancing messaging library and instead link to that? Might also be the way for Jörg's GUI #1714? @dl8dtl? Not sure this can happen before v8.0 but if people think this is a priority we could give it a go.

[ndim]

I have not looked into what exactly the CI builds (Windows+MSYS2/mingw or Windows/msvc) do, but statical linking should work.

For dynamic linking and message output functions, a usual pattern is that a library defines a C function type and offers an initialization function to its library users which takes a function of such type and some data to be handed to such a function.

So a library user like avrdude or avrgui registers its respective message handler with libavrdude when it initializes the library. Then avrdude's message handler be something like its current avrdude_message_2() and print to stdout, and avrgui's message handler would be a function which writes to a GUI log window.

A reasonable default implementation for such a message handler could be printing to stdout.

/* libfoo.h */
void (*message_handler_func)(void *data, char *msg);
void register_message_handler(message_handler_func *handler, void *data);

/* libfoo.c */
static void default_message_handler(void *, char *msg)
{
  fputs(msg, stdout);
}

static message_handler_func *message_handler = default_message_handler;
static void *message_handler_data = NULL;

static void foo_message(char *msg)
{
  message_handler(data, msg);
}

void foo_bar(...)
{
  foo_message("doing bar");
  ...
}

/* gui-application-using-libfoo.c */
void message_handler(void *data, char *msg)
{
  MainWindow *main_win = (MainWindow *)data;
  main_win.show_message(msg);
}

The respective message handler data and message handler func could be part of an opaque library context type struct.

Details to be determined.

[mcuee]

Please forget about Parport in Windows, it is not supported and will not work as there is no driver support.

[ndim]

Or avrdude_message2() could be moved from the avrdude executable into the libavrdude library. But unlike e.g. the warning messages Gtk GUIs print to the console, the messages printed through avrdude_message2() can be essential for the user to see, so they would need to be made available to a user in some way.

[ndim]

Please forget about Parport in Windows, it is not supported and will not work as there is no driver support.

ppiwin.c does not work on Windows? What was it written for, then? 16 bit Windows?

[mcuee]

Please forget about Parport in Windows, it is not supported and will not work as there is no driver support.

This has been documented under the Wiki here.
https://github.com/avrdudes/avrdude/wiki/Known-limitations-of-avrdude#known-issues-for-programmers

Parallel port based programmer will nork under Windows and macOS. The old version of avrdude ships with giveio.sys driver which may work under Windows XP but not later version of Windows. It was removed in the following PR.
#769

[stefanrueger]

avrdude_message2() could be moved [to] libavrdude [...] would need to be made available to a user in some way

I like this idea. avrdude_message2() could be a function pointer that can be overwritten by the user of that library. @dl8dtl?

[ndim]

So it would make sense to remove ppiwin.c and have the builds fail in whatever way when given cmake -D HAVE_PARPORT or configure --enable-parport.

[mcuee]

So it would make sense to remove ppiwin.c and have the builds fail in whatever way when given cmake -D HAVE_PARPORT or configure --enable-parport.

I like this idea.

[mcuee]

I have mentioned this as part of Docuementation improvement.

• avrdude documentation improvement  #1674

[mcuee]

@dl8dtl
Just want to double confirm with you to check if you are okay to remove Parallel Port under Windows. Thanks.

I look at the code and I do not think it will work under Windows Vista and later.

And we do not support Windows XP/Vista anyway. Even Windows 7 support is not tested now that it is no longer supported by Microsoft.

[dl8dtl]

avrdude_message2() could be moved [to] libavrdude [...] would need to be made available to a user in some way

I like this idea. avrdude_message2() could be a function pointer that can be overwritten by the user of that library. @dl8dtl?

I think I could live with that.

Just want to double confirm with you to check if you are okay to remove Parallel Port under Windows.

I don't think there was any actual parallel-port support for Windows available anyway since the days are gone when you could gain access to all IO ports through giveio.sys.

[mcuee]

Just want to double confirm with you to check if you are okay to remove Parallel Port under Windows.

I don't think there was any actual parallel-port support for Windows available anyway since the days are gone when you could gain access to all IO ports through giveio.sys.

Great. Thanks for your confirmation. This is what I believe as well.

[mcuee]

@ndim

Actually this PR is kind of good already. Just wondering any further changes you want to have. Thanks.

[ndim]

The commit comment is incorrect at least regarding Windows. Doc changes have been done in other PRs, expecting conflicts.

But you are right, this PR could be made merge able with probably low effort. Will try later today.

[mcuee]

@ndim

I have committed the document changes about Windows parallel port into git main. I also found another place mentioning Windows parallel port and I removed them as well. Thanks.

• 138bd51
• a959462

[mcuee]

@ndim

Please help to rebase this PR and fix the commit messages, then I think it will be good to go.

[ndim]

Good to go, as far as I can tell.

[stefanrueger]

Great, will merge soon