From the page:
-----
PR manager
Currently we almost have no Public Relationship management at all. This
should change for the better.
Currently almost the only form of PR is "preaching to the choir", since
we're having articles on online IT sites (by far most are Linux only !).
We should have much more coverage on traditional Windowsish sites and,
most importantly, in dead-tree newspapers, to enlighten the general
public also known as The Great Unwashed Masses !
-----
Wine users , CodeWeavers & WineX customers could do Previews/Demo's at there
local lug meetings as well.. This is what I did a couple months back and
it was a huge
success there were Windows users at the meeting to see Linux and Win
app's being
run on Linux ... Also it gives Linux users a look at wine as well.
So I suggest that we try to encourage wine users to volinteer to show
Wine at there
local user groups/Installfest/Computer shows and so on.
This is not a PR manager but it is PR......
Tom
What is wrong with using wcmd and extending it if necessary?
Chris
>
> From: "Jaco Greeff" <jaco(a)puxedo.org>
> Date: 2002/10/31 Thu PM 04:27:43 EST
> To: wine-devel(a)winehq.com
> Subject: RFC: msvcrt _popen/_wpopen/_pclose
>
> Hi,
>
> I want some comments on the possibility of a _popen/_wpopen/_pclose
> implementation in Wine. Reference available at:
>
> http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vclib/html…
>
> The open functions basically operate in the same way as the popen function
> in Linux, ie. it spawns a process with the command via the command
> interpreter. Now, unfortionately we don't have our won cmd.exe available,
> but should people really need this functionality it might not be too much to
> ask as to copy it from a working Windows installation.
>
> In my mind, supporting the Win 95/98 command interpreters might be a
> nightmare - my gutt feel is that these two rely too much on DOS internals to
> be sucessfully launched via Wine. No, I haven't tried it, so I might be
> completely wrong. Either way, something like this might be better
> implemented via the Win NT/2000/XP cmd.exe. (I'll test my assumptions
> tomorrow, I don't have access to the command interpreters tonight.)
>
> I've hacked (yes, it was quick) a potential implementation of the _popen
> family of functions. (Haven't compiled, haven't tested, this is just and RFC
> - if it can work, I'll spend some real time on it.) Anyway, here it is,
> comments appreciated:
>
> --[ inline-ish RFC ]----
>
> #include "config.h"
> #include "wine/port.h"
>
> #include <stdio.h>
> #include <stdlib.h>
> #ifdef HAVE_UNISTD_H
> # include <unistd.h>
> #endif
>
> #include "winbase.h"
> #include "winnls.h"
> #include "wine/unicode.h"
> #include "msvcrt/stdio.h"
> #include "msvcrt/string.h"
>
> #include "wine/debug.h"
>
> #define POPEN_FLAG_READ 0x0001
> #define POPEN_FLAG_WRITE 0x0002
> #define POPEN_FLAG_TEXT 0x0004
> #define POPEN_FLAG_BINARY 0x0008
>
> inline CHAR *LPCWSTRToLPSTR(const LPCWSTR lpwstrIn, INT nIn)
> {
> INT nLen = WideCharToMultiByte(CP_ACP, 0, lpwszIn, nIn, NULL, 0, NULL,
> NULL);
> CHAR *szOut = (CHAR *)malloc((nLen+1)*sizeof(CHAR));
> if (szOut)
> {
> WideCharToMultiByte(CP_ACP, 0, lpwszIn, nIn, szOut, nLen+1, NULL, NULL);
> szOut[nLen] = '\0';
> }
> return szOut;
> }
>
> INT POPEN_parseModeFlags(const CHAR *szMode)
> {
> INT nFlags = 0;
> while (szMode && *szMode)
> {
> switch (*szMode)
> {
> case 'r':
> {
> if (nFlags & POPEN_FLAG_WRITE)
> WARN(": _popen: Cannot set both read and write open
> flags, ignoring read flag\n");
> else
> nFlags = nFlags & POPEN_FLAG_READ;
> break;
> }
> case 'w':
> {
> if (nFlags & POPEN_FLAG_READ)
> WARN(": _popen: Cannot set both read and write open
> flags, ignoring write flag\n");
> else
> nFlags = nFlags & POPEN_FLAG_WRITE;
> break;
> }
> case 'b':
> case 't':
> {
> FIXME(": _popen: %c mode flag not implemented, ignoring\n",
> *szMode);
> break;
> }
> default:
> {
> WARN(": _popen: unknown mode flag %c, ignoring\n", *szMode);
> break;
> }
> }
> }
> return nFlags;
> }
>
> MSVCRT_FILE *MSVCRT_popen(const CHAR *szCommand, const CHAR *szMode)
> {
> MSVCRT_FILE *fProcess = NULL;
>
> if (!szCommand || !szMode)
> return NULL;
>
> INT nFlags = POPEN_parseModeFlags(szMode);
> if (!(nFlags & (POPEN_FLAG_READ|POPEN_FLAG_WRITE)))
> {
> ERR("No open mode flag r or w specified\n");
> return NULL;
> }
>
> /* _popen/_wpopen executes the required command via the command
> * processor, either command.com (Win 95/98) or cmd.exe (Win NT/2000/XP).
> * Wine does not currently have it's own "cmd.exe" hence we cannot
> * really do anything more at this point. However, we try to lauch it
> * and hope for the best...
> */
> CHAR *szExec = (CHAR *)malloc(strlen("wine -- C:/cmd.exe -C
> ")+strlen(szCommand)+1);
> if (szExec)
> {
> sprintf(szExec, "wine -- C:/cmd.exe -C %s", szCommand);
> fProcess = popen(szExec, (nFlags & POPEN_FLAG_READ) ? "r" : "w");
> if (!fProcess)
> ERR("Execution of C:/cmd.exe via wine failed\n");
> else
> WARN("Launch of %s succeeded, no guarentees of success made\n",
> debugstr_a(szExec));
> free(szExec);
> }
>
> return fProcess;
> }
>
> MSVCRT_FILE *MSVCRT_wpopen(const WCHAR *wszCommand, const WCHAR *wszMode)
> {
> MSVCRT_FILE *fProcess = NULL;
>
> if (!wszCommand || !wszMode)
> return NULL;
>
> CHAR *szCommand = LPCWSTRToLPSTR(wszCommand, strlenW(wszCommand));
> if (szCommand)
> {
> CHAR *szMode = LPCWSTRToLPSTR(wszMode, strlenW(wszMode));
> if (szMode)
> {
> fProcess = _popen(szCommand, szMode);
> free(szMode);
> free(szCommand);
> }
> free(szCommand);
> }
>
> return fProcess;
> }
>
> int MSVCRT_pclose(MSVCRT_FILE *fProcess)
> {
> if (!fProcess)
> return -1;
> return pclose(fProcess);
> }
>
>
>
>
That is,
Lets assume for the sake of argument that Alexandre likes my
0.8 idea so much, that he releases Wine 0.8 with much fanfare
next Monday (so we have a good audience), and the news reaches
Slashdot where a message with a link to http://www.winehq.org
is posted, in good CmdrTaco fashion...
And so, let's see what's going to happen:
1. 90% of /.ers will click on the link, and WineHQ gets Slashdotted! :)
2. People will look for the typical left-side menu:
Home
About
Status
Development
Download
Screenshots
*BZZT* We don't have any. 5% will drop off here.
3. Then they'll visually search for the word "Screenshot"
*BZZT* We don't have any on front page. 30% will drop off.
*I* drop off here when I visit other projects, for crying out loud!
So let's assume that by a miracle they'll discover the screenshots:
do they make them drool? No, we loose another 15%.
Damn, that's tough! Let's see what happens to the rest:
4. Let's download, and try it out
Do we have officially sanctioned binaries (at the very least
.rpms for RH, and .deb for Debian)? No. *BZZT* We loose another 30%.
Again, *I* don't care about stuff that doesn't come as a binary
.rpm for my RH system. I used to, not anymore.
Fine, some will install what they download. What next? Hm, this
Wine thing just sits there, it's not that simple. We need to
read some docs. Back to the site.
5. Look at the docs
Oh, we have some. We hate to read docs, but Wine is cool, so we
swallow the pill. Only to find out it's out of date!!! What a
piece of #@$%!
*BZZT* Another 10% drop off.
Thats 90% drop-off before they really tried it out! The rest 10%,
go on. So, what do we do with it?
6. Look for a list of Win-apps that we can run
Is there something on the site? No. Blah, too much hassel...
*BZZT* Another 5% go.
(Don't even mention app-db, it's *way* too complicated!)
So the 5% left, install wine, install a Win-app, and play around.
Great, it works! They start learning the utilities, etc., but
those are in flux, and we change them, and they get PO-ed. Another
percent, or two leave the fold...
--
Dimi.
P.S. A story-like TODO (with embedded rationale) for 0.8.0 :)
OK, it seems everyone but me is able to play War3 under linux.
Current status is i have the 1.03 NoCD patch:
³ Warcraft III: Reign Of Chaos 1.03 Virtual Crack ³
³ Cracked By : gimpsRus ³ Game Type : Strategy ³
³ Packaged By: gimpsRus ³ Released On: 10 October 2002 ³
I'm using the 'dataparty' RPMs build "wine-cvs-opengl-102802-1"
OpenGL is working and i can still load the warez beta version of war3
that i used to play.
Now that i have actually bought the damn thing i can't play :(
Here is the error i get:
[dantheperson@danski dantheperson]$ wine .wine/fake_windows/Program\
Files/Warcraft\ III/war3.exe -- -opengl
wine: Unhandled exception, starting debugger...
err:seh:start_debugger Couldn't start debugger ("debugger/winedbg
134692272 8324") (2)
Read the Wine Developers Guide on how to set up winedbg or another debugger
[dantheperson@danski dantheperson]$
Has anybody had success with the 1.03 patch? Does anyone know where i
can get an older NoCD crack that is known to be working under linux?
Rgds,
dan carter
Hi,
I want some comments on the possibility of a _popen/_wpopen/_pclose
implementation in Wine. Reference available at:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vclib/html…
The open functions basically operate in the same way as the popen function
in Linux, ie. it spawns a process with the command via the command
interpreter. Now, unfortionately we don't have our won cmd.exe available,
but should people really need this functionality it might not be too much to
ask as to copy it from a working Windows installation.
In my mind, supporting the Win 95/98 command interpreters might be a
nightmare - my gutt feel is that these two rely too much on DOS internals to
be sucessfully launched via Wine. No, I haven't tried it, so I might be
completely wrong. Either way, something like this might be better
implemented via the Win NT/2000/XP cmd.exe. (I'll test my assumptions
tomorrow, I don't have access to the command interpreters tonight.)
I've hacked (yes, it was quick) a potential implementation of the _popen
family of functions. (Haven't compiled, haven't tested, this is just and RFC
- if it can work, I'll spend some real time on it.) Anyway, here it is,
comments appreciated:
--[ inline-ish RFC ]----
#include "config.h"
#include "wine/port.h"
#include <stdio.h>
#include <stdlib.h>
#ifdef HAVE_UNISTD_H
# include <unistd.h>
#endif
#include "winbase.h"
#include "winnls.h"
#include "wine/unicode.h"
#include "msvcrt/stdio.h"
#include "msvcrt/string.h"
#include "wine/debug.h"
#define POPEN_FLAG_READ 0x0001
#define POPEN_FLAG_WRITE 0x0002
#define POPEN_FLAG_TEXT 0x0004
#define POPEN_FLAG_BINARY 0x0008
inline CHAR *LPCWSTRToLPSTR(const LPCWSTR lpwstrIn, INT nIn)
{
INT nLen = WideCharToMultiByte(CP_ACP, 0, lpwszIn, nIn, NULL, 0, NULL,
NULL);
CHAR *szOut = (CHAR *)malloc((nLen+1)*sizeof(CHAR));
if (szOut)
{
WideCharToMultiByte(CP_ACP, 0, lpwszIn, nIn, szOut, nLen+1, NULL, NULL);
szOut[nLen] = '\0';
}
return szOut;
}
INT POPEN_parseModeFlags(const CHAR *szMode)
{
INT nFlags = 0;
while (szMode && *szMode)
{
switch (*szMode)
{
case 'r':
{
if (nFlags & POPEN_FLAG_WRITE)
WARN(": _popen: Cannot set both read and write open
flags, ignoring read flag\n");
else
nFlags = nFlags & POPEN_FLAG_READ;
break;
}
case 'w':
{
if (nFlags & POPEN_FLAG_READ)
WARN(": _popen: Cannot set both read and write open
flags, ignoring write flag\n");
else
nFlags = nFlags & POPEN_FLAG_WRITE;
break;
}
case 'b':
case 't':
{
FIXME(": _popen: %c mode flag not implemented, ignoring\n",
*szMode);
break;
}
default:
{
WARN(": _popen: unknown mode flag %c, ignoring\n", *szMode);
break;
}
}
}
return nFlags;
}
MSVCRT_FILE *MSVCRT_popen(const CHAR *szCommand, const CHAR *szMode)
{
MSVCRT_FILE *fProcess = NULL;
if (!szCommand || !szMode)
return NULL;
INT nFlags = POPEN_parseModeFlags(szMode);
if (!(nFlags & (POPEN_FLAG_READ|POPEN_FLAG_WRITE)))
{
ERR("No open mode flag r or w specified\n");
return NULL;
}
/* _popen/_wpopen executes the required command via the command
* processor, either command.com (Win 95/98) or cmd.exe (Win NT/2000/XP).
* Wine does not currently have it's own "cmd.exe" hence we cannot
* really do anything more at this point. However, we try to lauch it
* and hope for the best...
*/
CHAR *szExec = (CHAR *)malloc(strlen("wine -- C:/cmd.exe -C
")+strlen(szCommand)+1);
if (szExec)
{
sprintf(szExec, "wine -- C:/cmd.exe -C %s", szCommand);
fProcess = popen(szExec, (nFlags & POPEN_FLAG_READ) ? "r" : "w");
if (!fProcess)
ERR("Execution of C:/cmd.exe via wine failed\n");
else
WARN("Launch of %s succeeded, no guarentees of success made\n",
debugstr_a(szExec));
free(szExec);
}
return fProcess;
}
MSVCRT_FILE *MSVCRT_wpopen(const WCHAR *wszCommand, const WCHAR *wszMode)
{
MSVCRT_FILE *fProcess = NULL;
if (!wszCommand || !wszMode)
return NULL;
CHAR *szCommand = LPCWSTRToLPSTR(wszCommand, strlenW(wszCommand));
if (szCommand)
{
CHAR *szMode = LPCWSTRToLPSTR(wszMode, strlenW(wszMode));
if (szMode)
{
fProcess = _popen(szCommand, szMode);
free(szMode);
free(szCommand);
}
free(szCommand);
}
return fProcess;
}
int MSVCRT_pclose(MSVCRT_FILE *fProcess)
{
if (!fProcess)
return -1;
return pclose(fProcess);
}
On October 31, 2002 04:18 pm, Andreas Mohr wrote:
> Bl**dy b*tch ! :-))
Listen man, I don't like that! I mean, what's up with the stars?!? :)))
> First you annoy the h*ll out of people, and then you behave as if nothing
> had ever happened and the weather was fantastic... ;-)
Oh, Andy dude, you are the toughest guy on Wine-devel, crushing poor
newbies without remorse. And now, all of a sudden, you become this
sensible, in-touch-with-your-feelings guy?!? ;-) (ROTFL)
> (BTW: the weather here is awful :)
See, and you blame poor me... :P
--
Dimi.
Could someone do something to make the need for this hardware disappear
and save the world of people who love proprietrary video game consoles?
There is already a tool that converts xpe files into exe. Only the bios
and the improved DirectX must be re-engineered and the rest will be done
by a Geforce4 (or 5) and a 2Ghz CPU.
Hi there;
I feel like I'm "nearly there" with porting this game to run with winelib, a
version checked out from winehq CVS about a week ago. Because I wanted my
build system to be cross-platform, and WINE only as a stop-gap, I'm using the
Jam build system and so can't directly take advantage of winemaker. Plus I
would rather learn and document how the build process works manually, since I
can't find this information anywhere else.
Anyhow I now have the 400-odd source files compiling happily against my wine
header files once I'd excised the need for Direct3D. I have a directory full
of object files with external references to Win32 functions and a WinMain
function.
So to do the final linking step I've used (based on watching the example
winemine build process):
$WINE/tools/winebuild/winebuild \
-fPIC -DSTRICT -D_REENTRANT \
-exe LSNClient.exe -mgui Builds/native-debug-linux/Source/*.o \
-L$WINE/dlls -luser32 -lgdi32 -ladvapi32 -lkernel32 -lddraw -ldsound \
-lwinmm -ldisplay -ldispdib >Source/LSNClient.exe.c
and then compiled & linked LSNClient.exe.c to the rest of the object files
with the -shared flag, which leaves me with a shared library.
Sideline: am I correct in thinking that winebuild's job is to scan the
supplied object files for Win32 dependencies and construct the necessary glue
code to load the needed .dll.so files? What's the reason that the linking
process can't correspond more closely to "normal" linking, i.e. where I could
just supply -lddraw -lwine to my program to produce a final binary?
I then run ../wine/wine LSNClient.exe to try to run the game, and get this
error:
err:module:BUILTIN32_LoadLibraryExA loaded .so but dll display.dll still not
found - 16-bit dll or version conflict.
err:module:PE_fixup_imports Module (file) display.dll (which is needed by
Y:\Work\Nemesis\LSNClient.exe) not found
Any idea what might be going wrong, or how I could diagnose it?
More generally, the natively compiled .exe runs okay (if grindingly slowly,
and with a couple of display glitches) under the binary loader, but I assumed
that if I could produce a native version I'd be avoiding a lot of overhead
and make my debugging job easier since I could use familiar GNU tools to
debug my portability code as I wrote it. What efficiency gains will I make
compiling a native "shared library exe" with gcc as opposed to just compiling
with Visual C and running it under the normal WINE binary loader? I'm
interested in how the latter works efficiently, so any advice in this
direction would be appreciated-- I've thought on more than one occasion that
maybe I should skip the WINE stop-gap and port it to SDL all at once, but the
idea of being able to gradually wean the game off Win32 is appealing.
cheers,
--
Matthew Bloch Bytemark Computer Consulting Limited
http://www.bytemark.co.uk/
tel. +44 (0) 8707 455026
> On Thursday 31 October 2002 09:20 am, Patrik Stridvall wrote:
> > Greg wrote:
> > > winapi_check tells me:
> > >
> > > ndr_stubless.c:86: rpcrt4: LONG_PTR WINAPIV
> > > NdrClientCall2(PMIDL_STUB_DESC,PFORMAT_STRING,...): argument 1
> > > documentation: \
> > > /* CLIENT_CALL_RETURN */
> >
> > This is because winapi_check misparser the line:
> > LONG_PTR /* CLIENT_CALL_RETURN */
> > RPCRT4_NdrClientCall2(PMIDL_STUB_DESC pStubDesc, PFORMAT_STRING
> > pFormat, va_list args)
> >
> > Ignore it.
>
> OK. You promise it won't screw up the actual documentation bot?
Promise? Hmm. All code have bugs you know and winapi_check is
designed to be ad hoc and thus inherently buggy... :-)
But seriously, I wouldn't worry about it.
Anyway. A real fix to the code you be nice.
Presumable the type CLIENT_CALL_RETURN haven't
been declared properly.
> > > how shall I deal with these?
> >
> > Fix them as above or do as everybody elses do wait for me to fix it.
> > :-)
>
> heh. Well, maybe I can set an example for those deadbeats :)
:-)
On Thu, 31 Oct 2002 17:57:12 +0100, Uwe Bonnes
<bon(a)elektron.ikp.physik.tu-darmstadt.de> wrote :
> Jaco> ... Tests that will fail
> Jaco> with current implementation are temporarily commented out
>
> Don't comment them out, matrk them "todo". Look at the syntax in
> documentation/testing.
I've marked the code with a "FIXME". I don't want the test sequence to fail
for this issue which is solved by my msvcrt patch. The way I've done it
allows others to verify the new vfprintf patch with minimal work.
> And plain inlined patches are preferred against attachments.
I'm doing this via a mail web interface, it has the ugly habit of doing
line-wraps. I also prefer inline patches (like to see what is going on
without have to save etc.), it is just not entirely possible for me at this
point. *sigh*
Greetings,
Jaco
