summaryrefslogtreecommitdiffstats
path: root/client/windows/redc.vcproj
Commit message (Collapse)AuthorAgeFilesLines
* client/windows: enable image randomization (ASLR) rhbz#701111Arnon Gilboa2011-05-301-2/+2
| | | | | | Enable image randomized base address, hindering some types of security attacks by making it more difficult for an attacker to predict target addresses.
* client/windows: remove slash from x64 build dirArnon Gilboa2011-05-301-4/+4
| | | | otherwise x64 is built in root if REDC_BUILD_DIR is not defined
* client/windows: remove precompiled header for common.h (fix broken windows ↵Arnon Gilboa2011-05-221-4/+4
| | | | | | | | debug build) -Release currently doesn't use precompiled headers at all -Debug is broken since common/*.c files don't include common.h -PCH can be enabled for all but specifically-chosen c-files
* client/windows: add common\ssl_verify.c/h to projectArnon Gilboa2011-05-121-2/+10
| | | | disable WarnAsError, due to c/c++ warnings
* win32: remove obsolete preprocessor #definesChristophe Fergeau2011-05-031-4/+4
| | | | | | SW_CANVAS_NO_CHUNKS isn't used anywhere but in this file. SW_CANVAS_CACHE is now defined directly in the files where it's needed so we no longer need it in the .vcproj file.
* autotools: correctly build canvas-related codeChristophe Fergeau2011-05-031-8/+0
| | | | | | | | | | | | | | | | | | | | | spice client and spice server shares code from common/{gdi,gl,sw}_canvas.[ch]. However, while most of the code is shared, the server code wants a canvas compiled with SW_CANVAS_IMAGE_CACHE defined while the client code wants a canvas compiled with SW_CANVAS_CACHE. The initial autotools refactoring didn't take that into account, this is now fixed by this commit. After this commit, the canvas files from common/ are no longer compiled as part of the libspice-common.la convenience library. Instead, there are "proxy" canvas source files in client/ and server/ which #include the appropriate C files after defining the relevant #define for the binary that is being built. To prevent misuse of the canvas c files and headers in common/, SPICE_CANVAS_INTERNAL must be set when including the canvas headers from common/ or when building the c files from common/ otherwise the build will error out.
* client: remove c++ wrappersChristophe Fergeau2011-05-021-11/+11
| | | | | | | | client/ contains several .cpp file which only #include a .c file of the same name. This is unusual and seems to only be done to get C++ name mangling on the symbols defined in the C file. Now that all headers files in common/ use extern "C", these wrappers are no longer useful.
* client/windows: cleanup vcproj based on updated libsArnon Gilboa2011-03-081-8/+8
| | | | | | | | | | | | | | | | using updated windows libraries: http://www.spice-space.org/download/stable/wspice-x86_08032011.zip http://www.spice-space.org/download/stable/wspice-x64_08032011.zip -remove IgnoreDefaultLibraryNames="MSVCRT.lib", since pixman is now compiled using MT threading model similar to other libraries. It used to be mistakenly compiled with MD. -downgrade freetype lib to 2.3.11-7, which is the one used/tested with CEGUI 0.6.2 -pthread lib patched (InterlockedCompareExchange), so x64 client will no longer crash on SelectClipRgn, BitBlt etc.
* client/windows: use SPICE_PROTOCOL_DIR in project include dirsArnon Gilboa2011-02-131-4/+4
| | | | | | | | | instead of ..\..\..\spice-protocol. Relative path to another git tree is a bit ugly, since it requires spice-protocol to be in a specific location. SPICE_PROTOCOL_DIR should also be used in windows qxl and vdagent instead of SPICE_COMMON_DIR, which is an old and confusing name, due to the common directory in spice git repo.
* spicec: Remove spice-client watermark (rhbz#662450)Hans de Goede2010-12-161-4/+0
| | | | | | | | This patch stops us from drawing the spice client watermark at the top of the virtual machine view. We have had requests through several channels to remove this as it has little added value, and is seen as annoying by some. Given that we now also have a bugzilla for this I think it is time we really remove it.
* spicec-win: add image copy-paste supportArnon Gilboa2010-11-241-8/+8
| | | | | | -currently png & bmp -using wspice libs cximage.lib & png.lib -jpg & tiff will follow
* spicec-win: ignore MSVCRT.lib in x86 buildArnon Gilboa2010-11-081-2/+3
| | | | Same as in x64 build, for using the updated wspice-0.6.3
* spicec-win: add x64 to vcproj & sln (v2)Arnon Gilboa2010-10-251-0/+236
| | | | use CEGUI for x64 as well, no need for the SUPPORT_GUI hack
* spicec: add controllerArnon Gilboa2010-10-181-0/+8
| | | | | | | | | | | Spice client controller enables external control (e.g., by XPI or ActiveX) of the client functionality. The controller protocol enables setting parameters (host, port, sport, pwd, secure channels, disabled channels, title, menus, hotkeys etc.), connecting the server, showing and hiding the client etc. The controller is based on the cross-platform named pipe.
* spicec: add foreign menuArnon Gilboa2010-10-181-5/+13
| | | | | | | | | Spice foreign menu enables external control of the client menu. The foreignmenu protocol enables an external application to: add a submenu, set its title, clear it, add/modify/remove an item etc. Foreign menu is based on the cross-platform named pipe.
* Disable tunnel by default on windowsAlexander Larsson2010-07-081-8/+0
|
* Make CEGUI optionalAlon Levy2010-07-011-2/+2
| | | | | This makes the CEGUI dependency optional and off by default. Restoring previous behaviour of exiting on disconnect if disabled.
* Replace log4cpp with custom log functionAlexander Larsson2010-06-281-4/+4
| | | | | Also prints a simpler error to stderr for WARN or above so that we print something on the commandline if something go wrong.
* Generate marshaller/demarshallers for old protocolAlexander Larsson2010-06-221-10/+39
|
* applying zlib compression over glz on WAN connectionYonit Halperin2010-06-211-2/+10
|
* Make generated marshallers build on win32Alexander Larsson2010-06-181-8/+20
|
* Generate demarshalling code on win32 tooAlexander Larsson2010-06-181-13/+50
|
* Client: Use the autogenerated demarshallersAlexander Larsson2010-06-181-2/+2
| | | | | | | | | | | | | | | | When a message has been read from the network we now pass it into the generated demarshaller for the channel. The demarshaller converts the network data to in-memory structures that is passed on to the spice internals. Additionally it also: * Converts endianness * Validates sizes of message and any pointers in it * Localizes offsets (converts them to pointers) * Checks for zero offsets in messages where they are not supported Some of this was previously done using custom code in the client, this is now removed.
* JPEG support: introducing jpeg encoding for spice bitmapsYonit Halperin2010-06-091-0/+8
|
* Remove all mentions of "cairo" from the codeAlexander Larsson2010-05-031-6/+6
| | | | | The command line option is renamed from "cairo" to "sw", and similarly all filenames and types from Cairo to Sw (and similar).
* Use upstream name for pthreads lib and new freetype versionAlexander Larsson2010-04-121-2/+2
|
* Use libjpeg to decode mjpegs, not ffmpegAlexander Larsson2010-04-081-4/+12
| | | | | | | | | | | | | | | | | | This is pretty straightforward, although there are two weird issues. The current encoder has two bugs in the yuv conversion. First of all it switches red and blue, due to something of an endianness issue. We keep this behavior by switching red and blue. Maybe we want to change this in the new protocol version since switching this may cause jpeg compression to be worse. Secondly, the old coder/decoder did rgb to/from yuv420 wrongly for jpeg, not using the "full scale" version of Y that is used in jpeg, but the other one where y goes from 16 to 235. (See jpeg/jfif reference on http://en.wikipedia.org/wiki/YCbCr for details.) The new decoder uses the full range in order to get better quality, which means old encoders will show slightly darker images. This completely removes all ffmpeg usage in the client
* Update project file to visual studio 2008Alexander Larsson2010-04-081-7/+6
|
* New memory allocators that exit on OOM and handle multiplication overflowAlexander Larsson2010-03-111-0/+4
| | | | | | | | | Every place that does a regular malloc/calloc and aborts on failure should use spice_malloc/spice_mallo0 instead, which is leaner and cleaner. Allocations of dynamically sized arrays can use g_malloc_n or g_new etc which correctly handle multiplication overflow if some of the arguments are not trusted.
* Fix up win32 build reference to pixman_utils.cppAlexander Larsson2010-03-051-1/+1
| | | | It was pointing to the wrong directory for pixman_utils.cpp
* Update visual studio project for pixman changesLarsson@.(none)2010-03-011-4/+12
|
* Remove no longer needed CAIRO_CANVAS_CACH_IS_SHARED define and codeAlexander Larsson2010-02-231-2/+2
|
* client: use spice icon instead-of solidice iconYaniv Kamay2010-01-041-1/+1
|
* client: remove splash imageYaniv Kamay2009-12-281-4/+0
|
* client: add GUI infrastructure + functional login dialogYaniv Kamay2009-12-281-0/+16
|
* client: add soft renderer and ceguiYaniv Kamay2009-12-281-6/+22
|
* win client: change avcodec version to 51Yaniv Kamay2009-12-241-2/+2
|
* spice client: sticky Alt activation when holding an Alt key: bug #505912.Yonit Halperin2009-11-151-0/+4
| | | | | | | | | | | Additional changes that were required for the feature: 1) focusing on the pointed window in full screen mode 2) In X11 - handling events that occur during keyboard ungrabbing 3) In X11 - handling Leave/Enter Notify events that occur during keyboard grabbing/ungrabbing 4) In X11 - fix for focus events that are handled in the wrong order (happens when focus events occur during grabbing the keyboard) 5) In X11 - ignoring key release events during key holding 6) In Windows - synchronizing keyboard release events that occured during a modal loop
* spice client: Transfer all channels run loop from EventsLoop class to ↵Yonit Halperin2009-11-091-12/+0
| | | | ProcessLoop class
* spice client: creating a general process loop.Yonit Halperin2009-11-091-0/+20
| | | | | | | | | | | The process loop is responsible for: 1) waiting for events 2) timers 3) events queue for actions that should be performed in the context of the thread and are pushed from other threads. The benefits: 1) remove duplicity: till now, there was one implementaion of events loop for the channels and another one for the main thread. 2) timers can be executed on each thread and not only on the main thread. 3) events can be pushed to each thread and not only to the main thread. In this commit, only the main thread was modified to use the new process loop.
* fix build on DebianYaniv Kamay2009-10-261-2/+2
|
* tunnelYonit Halperin2009-10-181-0/+16
|
* fresh startYaniv Kamay2009-10-141-0/+597