Boaz Harrosh wrote:
I did something similar.
I used X, and have written an IE embeddable OCX that automatically
Installs X-Server and connects to the X applications on the server, in
my case they are Windows apps running under wine. So basically you set
up a web server on your Linux machine.
different apps you want to serve. The user uses IE to navigate to that
page. When clicking, the App comes up as a window in his/her machine.
First time visit Installs a 12M Cygwin/X server.
I really like the concept but your approach seems to limit publishing of apps
to Windows boxes.
Hans Leidekker wrote:
I really like the concept but your approach seems to limit publishing of apps
to Windows boxes. Theoretically you could run the OCX (Internet Explorer) on
Wine and the Cygwin/X as well but not practically though, if only from a
performance point of view.
It would be more
On Monday 1 November 2004 16:27, Boaz Harrosh wrote:
Actually all it is on windows is a shell access with an invocation of
ssh -X, And the regular IE's safe-for-scripting stuff.
(ssh is installed along side with the cygwin/X server)
I think the use of ssh is a good choice because it let's
Hans Leidekker wrote:
different apps you want to serve. The user uses IE to navigate to that
page. When clicking, the App comes up as a window in his/her machine.
First time visit Installs a 12M Cygwin/X server.
I really like the concept but your approach seems to limit publishing of
Dan Kegel wrote:
Likewise, what's the current status of Installshield support,
and how much work would it be to fully support
Installshield-based installers? I don't see any
open Installshield bug reports, maybe I should file
one against the apps I have that don't install at
the moment. (Or
I asked the List about the Problem and how to solve it correctly.
Please excuse my bad English (: - will try your patch asap.
Tho
Why are you saying that. The code treats LVN_GETDISPINFOW special
because it's the only type of message that *gets* textual data
rather then sending. SO for this
On Monday 1 November 2004 17:38, Markus Amsler wrote:
My approach was the following:
Server side:
- defining a mime-type application/x11-control (or something similar)
- a x control file, with all the information to connect to the
Defining your your own mime-type has a disadvantage in
Dmitry Timoshkov [EMAIL PROTECTED] writes:
And please merge your test into existing win.c tests.
Actually I think it's fine to have separate test files for controls,
we already have a listbox.c so we can have an edit.c. The guideline is
that the layout of the test directory should be close to
Hi folks,
Due to my new found belief that all of the flaws in Wine
are timing problems, I have found what appears to be a
gaping hole in Wine's timing behavior.
Specifically, it appears as though any style of
Waitxxx is supposed to yield the processor.
This seems a bit difficult for me to believe,
I'm trying to get the wine tests to compile under msvc, so I ran
msvcmaker in the wine source under cygwin (which was successful).
Then I opened the winetest project and did a 'rebuild all'. When it
tries to compile advapi32_test/security.c I get an warning and 102
errors:
C:\Program
Should I then go for take 3 then? I have added few more tests in take 2. Mainly
for styles being consistent with native.
Monday, November 1, 2004, 12:33:38 PM, you wrote:
Dmitry Timoshkov [EMAIL PROTECTED] writes:
And please merge your test into existing win.c tests.
Actually I think it's
On Mon, 1 Nov 2004, James Hawkins wrote:
[...]
I'm pretty sure the problem is that the the msvc's rpc.h and rpcnsi.h
files are being included when they shouldn't. Is that about right?
If so, what could be a possible solution?
BTW I'm compiling with MSVC++ 6.0. wine cvs from 11-01-2004.
Two
* You say that you use MSVC 6.0. Did you also install a recent Platform
SDK? If not the tests won't compile as stated in the above
documentation.
I have not done that yet. I will install the platform sdk and then
see if it works.
On Tue, 2 Nov 2004 01:10:41 +0100 (CET), Francois Gouget
Hi,
This patch doesn't aplly smoothly, because you did the cvs diff not from
the wine-root directory.
do: at ~/src/wine$ cvs diff -u dlls/msvrt/tests/file.c
You can test if your patch apllies with
$ patch -p0 file.diff
from the wine root. If there are no error messages the format is fine.
To
Ryan Underwood wrote:
On Sat, Oct 30, 2004 at 04:32:02PM +0200, Holly Bostick wrote:
find that it doesn't necessarily feel strange or at least as strange
as I might have imagined. What mostly feels strange is the complications
of getting the program started in the first place (having to cd to
On Tue, Nov 02, 2004 at 01:10:41AM +0100, Francois Gouget wrote:
As of a few days ago, I was able to compile all of the Wine conformance
tests (not the Wine dlls themselves) using: the MSVC targets, MSVC 6.0,
a recent Platform SDK and a recent Direct X SDK.
It would be really cool if we:
I have installed the latest platform SDk and directx SDK, and set up
msvc per http://www.winehq.org/site/docs/wine-devel/testing-windows,
but I get this error when compiling dsound_test:
Linking...
uuid.lib(unknwn_i.obj) : fatal error LNK1103: debugging information
corrupt; recompile module
Error
18 matches
Mail list logo
