Open higunjan opened 3 years ago
We use Visual Studio 2017/20190 + nasm Normal it should work out of the box if you open the project sln files. Using mingw you need to create your own projects, include paths unless mingw have a visual studio convert options.
Hello @RudiDeVos, I tried to look into this wine issue, but as the official packages seem not to contain debug information and even if they would, it would not be compatible with gdb I guess, I tried to build vncviewer with mingw. This effort is in this branch. Maybe you see something you consider worth applying upstream? Unfortunately I have currently no VisualStudio at hand to test if these changes break building with it. It builds just the vncviewer.exe. A short description how to build is in cmake/readme.txt. I gave it just a short test and it was able to connect, show a picture, and interacts with the mouse :smiley:
Just tested with Visual Studio and it compiles. Only keymap.h had some issue's ( unicode char warnings) Solution was to copy changes in the existing keymap.h, looks like the way the file is saved make VS not happy.
I don't see any code changes that could fix the not connect issue, is the mingw exe working ? If that's the case, rebuilding the vncviewer with the toolset and SDK used in 1.3.2 would also fix it. TextChat.cpp : is change needed ?
I don't see any code changes that could fix the not connect issue, is the mingw exe working ?
I just mentioned this to give a reason why I was trying to build with mingw. And there is no change included that tries to change UltraVNC, because it runs at Windows, so normally this means Wine has to be fixed. If there would be a such a change I assume this should go in its own issue or pull request, as this issue here is about building the executables?
I have looked a little further in building with Mingw and pushed new commits to my branch which enable building now both, vncviewer.exe and winvnc.exe. I did a little test and it looks like both are working for connecting, viewing and mouse interaction.
The actual change to TextChat.cpp is not needed, just Qt-Creator warned about the encoding.
I removed that change from my branch. The offending character seem to be something like Break Permitted Here (BPH)
and No Break Here (NBH)
- I don't know if that is right or even needed here.
But the KeyMap.h gives this error:
KeyMap.h:173:31: error: converting to execution character set: Invalid or incomplete multibyte or wide character
173 | {XK_dead_acute , L'�' }, // +U00A8
I found now that I can also specify the input encoding to the compiler by -finput-charset=ISO-8859-1
.
With this the error does not show up.
EDIT: Unfortunately I did not do a full rebuild - with -finput-charset=ISO-8859-1
e.g. VirtualDisplay.cpp throws an error, which has an encoding Unicode text, UTF-8 (with BOM)
.
My last conversion attempt of KeyMap.h was from ISO-8859-15 to UTF-8 without BOM, maybe this conversion now with BOM works better?
While looking at following I found that the comments +U00A8 and +U00B4 are switched:
I guess you are not against it, if I create pull requests for the smaller and less risky changes?
@bernhardu: Thanks for PR :) It is better now?
@RudiDeVos : Thanks for merging the first part.
@Neustradamus : It's better, but these first changes were just the simple ones, there are more here (the least questionable ones committed first), for which I want to send in separate PRs. Any favourites to work on next? I guess I should install somewhere a VC19 community edition to avoid breaking something...
Thanks,
The 1.3.8 release was needed before looking at the seconds part. Now that the development is merged i will add the other parts and run some tests. Let's hope there are not to many conflicts with the new codes.
Hello, sorry for my late response. I have rebased my branch on top of 1.3.8 and made sure it compiles again (did not test the resulting executables). (Mostly just added LayeredWindows.cpp. Is black_layered.cpp supposed to stay as empty file in the repository?) As said before, these patches are not intended for inclusion right away, especially the later ones, and more intended as a start for discussion ... Thanks for looking at it.
black_layered.cpp i guess i only removed it from the project, but forgot git.
@bernhardu: All your improvements have been added in master code?
@bernhardu: All your improvements have been added in master code?
Hello @Neustradamus, those changes in my branch are most useful if someone wants to use a non MSVC-compiler. But they got not added to master code. Some changes are not suitable for inclusion, but they might be suitable as a start for discussion. Nevertheless I have rebased my branch on top of the current development branch. If you want to have this issue closed I am fine with it, as the issue submitter did not yet comment on it and there was no much response to generally support mingw or clang.
Hello @RudiDeVos, while I did this rebase I found a file winapifamily.h that I guess was not intended to reach the git repository, was it?
Header removed, wasn't used.
@bernhardu: Nice to see your branch!
@RudiDeVos: What do you think?
This isn't working in all cases
strncat_s(buffer, /buflen,/ digtxt, (buflen - 1) - strlen(buffer)); fail as sizeof(buffer) = 1
This isn't working in all cases #define strncat_s(dest, source, len) strncat_s(dest, sizeof(dest), source, len)
strncat_s(buffer, /buflen,/ digtxt, (buflen - 1) - strlen(buffer)); fail as sizeof(buffer) = 1
Thats one of the todo patches, where I am not certain and did add it just to get compile for now.
I had another look and found that Microsoft has a template strncat_s
that takes just three parameters.
Unfortunately the mingw headers do not contain that template as far as I see.
I guess I still should install some VisualStudio to check if those patches compile there too.
It actual compile, it's during runtime i got this error.
Your patches were added to development ( still in a local branch ) , and current i'm just testing if all still works. Then they can be added to the sourcetree. Current mapping out strncat_s changes for Visual studio builds
All Todo's where not included, still require work. I also needed to revert the min max patch
The windows.h header (or more correctly, windef.h already include min and max. This conflict with std::min std::max Viewer fails to build
I also needed to revert the min max patch
The windows.h header (or more correctly, windef.h already include min and max. This conflict with std::min std::max
To avoid the definition of min/max by windef.h it is possible to define NOMINMAX
before including windows.h.
The other way around might be to avoid some using std
and add explicit namespaces where needed.
Which way looks more promising to you?
NOMINMAX wasn't working. Still got std::min errors Possible solution is to
and replace the min by minimize
std:min was also complaining about the type use to compare.
development branch updated without minmax and todo
Thanks for taking your time to look at those changes.
It took me some time to setup a VS community edition. Unfortunately it is a 2022, but I guess using following at the VS command prompt should be equal (when adding the v141 packages to the VS installation.)
msbuild /p:WindowsTargetPlatformVersion=10.0.22000.0 /p:PlatformToolset=v141 /p:Configuration=Debug ...\UltraVNC\winvnc\winvncVS2017.sln
One issue I got in the viewer, which is caused by the Mingw has not yet natupnp.h, disable functionality.
patch, is uvnc_settings2\uvnc_settings\upnp.cpp(281): fatal error C1020: unexpected #endif
.
Looks like it is caused by having #if !defined(__MINGW32__)
above the includes. Moving it below the includes makes this go away.
Hello, I tried now several things with my community 2022 edition. This led to the patches collected in this branch. The min/max patch touches now less lines, and compiles for me with VS too. The strncat_s tries to implement the needed template overloads instead of the previous ugly define. The other patches are either untouched compared to the previous branch or might be helpful to have speed up building, and a few link library and path changes. This state can also be compiled with the cmake included in VS on windows :smiley:
Current tracing bugs in a refactor I did in Aug. I will check your changes later
@RudiDeVos: Have you looked @bernhardu improvements and @KangLin comment?
Just to help others trying to get this working: OS : Windows Server 2019 I installed VS2022 and NASM following this guide: https://www.stefanobordoni.cloud/howto-integrate-nasm-with-vs2019/
Very simple and straight forward. When opening the sln file, You'll have to rebase the project using Windows10 SDK etc.
One last thing: Edit uvnc_settings\uvnc_settings\upnp.cpp and comment the last line, the #endif or You'll get errors. OR Click : Build -> Configuration Manager, uncheck build column for uvnc_settings After commenting the line OR disable uvnc_settings build, the winvnc project built just fine in VS2022:
26> Creating library x64\Debug\winvnc.lib and object x64\Debug\winvnc.exp
26>winvnc_VC2017.vcxproj -> C:\Users\ansible\source\repos\UltraVNC\winvnc\winvnc\x64\Debug\winvnc.exe
26>Done building project "winvnc_VC2017.vcxproj".
========== Build: 23 succeeded, 0 failed, 0 up-to-date, 3 skipped ==========
========== Elapsed 03:22.832 ==========
The purpose of my setup was just to create a pull request to make Logging a bit more "Normalized" for winvnc server. I did my best for the PR... the logging code is very confusing for someone who doesn't know much of C/C++ ....
But my real goal is to get MSLogon username available for the LOGEXIT message.
Another hint for those not very confortable with C/C++: Build debug versions while testing changes, and whenever a bug window popup, try REBUILDING instead of BUILDING the project. Sometimes, nasty things happen when building only changes. Or just the fact that a rebuild was necessary, means that the code is not really OK ( pointers, assembler, etc ) ?
@ all: Improvements are welcome, have you?
Do I understand it correctly that UltraVNC client can run on both GNU/Linux and Windows systems? I haven't found linux related packages anywhere...
What build system does the Visual Studio use in the background? Is it cmake
? I've seen many files related to cmake
build system.
If that's true, than it should be relatively straight-forward to provide a manual for the users to compile from the command line without the Visual Studio dependency (which I don't have on my system).
Do I understand it correctly that UltraVNC client can run on both GNU/Linux and Windows systems? I haven't found linux related packages anywhere...
The cmake files are intended to run either at windows or linux with the mingw compilers, but always just for building the windows executables. Unfortunately I fear I have not yet catched up with latest UltraVNC development in the cmake files. Also if the build succeeds the produced binaries got not yet much testing. "UltraVNC for linux" would be a bigger effort as it uses currently many windows specifics.
What build system does the Visual Studio use in the background? Is it
cmake
? I've seen many files related tocmake
build system.
The Visual Studio solutions do not make use of the cmake files in the background (yet).
Current it isn't possible, ui need to be seperated from the code to be able to try to build the pure c++ lib for linux.
@msilveirabr, @tomichec, @higunjan, @KangLin, @bernhardu: @jose94752 has added some codes:
Maybe you can see to add other improvements too?
Thanks in advance.
Please write some README.md to guide how to build the exe from source code.
Atlease you can provide for Ultravnc Viewer and Ultravnc Server.
I tried it with g++ but through me an error
rfb.h:53:10: fatal error: rfb/gii.h: No such file or directory
.Can you please guide me how can we do it?