Re: Will simulavr support the Windows platform?

[Thomas K]

Hi Helge,

it's right, that (at least in the moment :-) ) simulavr 1.1 does only 
build with linux. Problem was, that I use only linux and it's possible 
to use simulavr with docker, even on windows.

But why not re-integrate windows support. The main problem is, that we 
need somebody, who can support an test changes and new versions on 
windows! If you like, youre most welcome. :-)

My question is: do you use only simulavr as application for debugging 
with gdb? Or do you use also python or tcl extension?

For getopt you could have a look into old directory, there is the getopt 
from version 1.0. Also the needed parts for windows in gdbserver.cpp - 
you could have a look in older versions.

To create a separated version of CMakefile.txt explicit for windows is, 
in my opinion, not a good idea.

I would recommend to start with a dev branch, where you change all, 
what's needed, to get it running native on windows. After that we can 
start to compare and what's possible to merge together. One step after 
another.

I'm not sure if the problem with the AVR_REGISTER macro is a linker 
problem. This could become a hard nut. Binding again static lib could be 
a problem, if you want to use python or tcl extension. But we'll see ...

What's really needed is, to get a documentation, what's needed for build 
simulavr on windows and how to do that. Maybe you could have a look into 
doc/sphinx directory.

And feel free to ask. Maybe I will not answer quickly ... it's a 
question of spare time ... but I'll try to answer.

cu, Thomas


Am 25.10.20 um 14:23 schrieb Helge Kruse:
> Hello,
>
> The support for Windows has been dropped with simulavr 1.1.
>
> But I would like to use the simulator on the Windows platform. I have
> compiled the current version with VS2017 Community Edition. This
> required some changes of the CMake output as well as at the source
> files. Here are the necessary changes:
>
> The Windows socket layer requires some changes:
>
> - different set of include files.
> - call to WSAStartup/WSACleanup
> - call to _read() or recv() instead of read(), same applies to write()
>
> The getopt module is not part of th Windows run time library and had to
> be added from source.
>
> The static constructors caused by the AVR_REGISTER macro invocation
> doesn't work with the Microsoft linker. The reason is, that the linker
> only uses object modules that resolve undefined symbols. As a
> workaround, the simulavr currently links againts the static library
> sim_static.lib and all object modules are forced to be included with
> /WHOLEARCHIVE:sim_static.lib.
>
> These changes require a change of the source code. Some "#ifdef WIN32"
> can be used to make the adaption to the winsock subsystem. The getopt
> module must be added or referenced by the simulavr project. Probably the
> remaining changes can be done with a Windows specific CMakefile.txt.
> Since CMake requires only one CMakefile.txt in a directory, the Linux
> and the Windows build should get their own directories.
>
> So, that's my idea of regaining the support for Windows of simulvar 1.x.
> What do you think about it? Is it still desired to maintain a
> cross-platform program? In that case I could  try to add my changes and
> (honestly  current) hacks to a Git repository after improving the code
> quality (remove hacks, etc.).
>
>
> Best regards,
> Helge