Re: Winelib and static-build

[Boaz Harrosh]

Dan Kegel wrote:
> On Sat, Oct 25, 2008 at 8:10 AM, Alan Nisota <[EMAIL PROTECTED]> wrote:
>   
>> Very cool.  Here is what I did:
>> In linux (host):
>> use shm_open and ftruncate to create a shared-memory region (this will be at
>> /dev/shm/ in linux)
>> use mmap to map that into memory
>> create a socket to use as a semaphore
>>
>> In the windows executable:
>> use CreateFile to open Z:\dev\shm\
>> use CreateFileMapping and MapViewOfFile to map that into memory
>> open the above socket
>>
>> I can now pass info back and forth between wine and linux via shared memory,
>> 
>
> Sweet!  I had forgotten about /dev/shm.
>
>   

If your going the win32 executable way. then do something much easier here.
Create a winelib (plugin) DLL that exports a stable API to your win32
application.
But then, since it is a winlib dll project you can use any Linux native API
easily. Be it /dev/shm or what ever you want. But you get to use pure
Linux API.

This will also solve your below problem.

>> The next question is whether this can be made more portable so it could be
>> used on Mac as well (I've yet to be able to make my loader work on Mac, and
>> this theoretically could if I could figure out how to use something like
>> tmpfs there).  I am not knowledgable about whether BSD/OSX has anything
>> equivalent to tmpfs.
>> 
>
> I just looked a bit, and it doesn't quite look like MacOSX's
> shm_open creates a visible file in the same way it does on Linux.
> So I'm not as optimistic there...
> - Dan
>   
In MacOSX have another implementation for your plugin winlib DLL and so
a plugin
part for your application. Here using MacOSX native API.

After saying all that. I don't share the wine guys opinion about
winelib. I think you
can have a very tight operation with a winelib project. You will see
that it is very
easy to package a private copy of wine and with use of a private
WINEPREFIX in
scripts you get a nice private operation that is not influenced from any
wine installation
in the system. You start with a full wine self-compiled installation,
then it is very easy
to just delete anything your winelib app does not use. Once you have
your minimal set
of wine dlls/exes, You check out their Linux dependencies and
individually tweak link
options for full control over outcome. And since you have your own
compiled copy of wine
the API stability is your own choice.

Just my $0.017
Boaz

Re: Thunderbird warning repeat - use --attach

[Boaz Harrosh]

Jeremy White wrote:
> So it seems as though every month or so, some id10t is bit by
> the Thunderbird bug where it mangles perfectly reasonable looking
> git-format-patch drafts.
> 
> This month, I won the prize! :-)
> 
> I had always habitually done --attach, because that's what GitWine says to do.
> But after scratching my head, reading man pages, and
> checking my drafts, I decided that was lame; inline is always nicer, and
> I dropped the --attach.  Big mistake; the draft may look okay, but the end 
> result
> is mangled somehow.
> 
> Thanks to Dmitry for alerting me.
> 
> I've filed a bug with Mozilla over this:
>https://bugzilla.mozilla.org/show_bug.cgi?id=435020
> 
> My sense is that its a subtle bug of some kind; I've had a hard
> time articulating a strategy to reproduce it (which, by Occam's
> razor, immediately suggests I'm just missing something :-/).
> 
> So if others are bit by this and can share any clues or tips
> for the Mozilla devs on how to reproduce it, I'd appreciate it.
> 
> Cheers,
> 
> Jeremy
> 

It's a known issue with Thunderbird and git. you need to set
mailnews.send_plaintext_flowed = false
and 
mailnews.wraplength = 0

Cheers 
Boaz

Re: COM

[Boaz Harrosh]

- Original Message -
*From:* Adelle Hartley <[EMAIL PROTECTED]>
*To:* wine-devel@winehq.org
*Sent:* Mon, Dec 10 2007 at 19:06 +0200
*Subject:* COM


> Hi all,
>
> I have some COM DLLs which work fine with VB6 applications on wine.
>
> Is it possible to instantiate a windowsy COM object from a linuxy
> application written in some form of C++ (eg, for compilation with gcc)?
>
> Adelle.
>
>   
You can use a C++ winlib and directly call the COM's C++ API.
It works like a charm. MinGW and Linux. C++ winlib is just your regular
winelib Makefile, with some files named .cpp the gcc will automatically
invoke g++ on them. Regular C-to-C++  linking rules apply.

GCC command line switches are the same, with 16-bit Unicode strings and
others. One more switch that you might need is that -m something that causes
all functions to use the __stdcall, because some versions of GCC have bugs
in regard to function pointers to __stdcall methods. But the regular
CoCreateInstance()/
abstract-class call works in all modes.

Happy COMing
Boaz

Re: Wine Gecko packaging

[Boaz Harrosh]

- Original Message -
*From:* Jacek Caban <[EMAIL PROTECTED]>
*To:* Dmitry Timoshkov <[EMAIL PROTECTED]>
*CC:* wine-devel@winehq.org
*Sent:* Wed, Oct 31 2007 at 21:20 +0200
*Subject:* Wine Gecko packaging


> Hi Dmitry,
>
> Dmitry Timoshkov wrote:
>   
>> http://source.winehq.org/winegecko.php still points to an old Gecko
>> package
>> (0.0.1). Please update it.
>>
>> 
>
> We can't change it due to compatibility with older Wine versions. We
> encode Gecko version in URL instead, so
> http://source.winehq.org/winegecko.php?v=0.1.0 will do what you want.
>
> Jacek
>   
Do you have a magic param to download the latest one available?
something like: winegecko.php?v=latest

Thanks
Boaz

Re: Helping a user migrate an odbc app to Wine

[Boaz Harrosh]

On 2/8/07, Rolf Kalbermatter <[EMAIL PROTECTED]> wrote:

Ouch, I wouldn't see how this could work. Running the Microsoft
drivers together with the whole Microsoft ODBC manager under Wine
too would probably be the only way to get that working. But I think
it is safe to assume that that would require quite some work in Wine
before this could possibly work, not to talk about license issues.

Rolf Kalbermatter




This is totally not true and it is right there in documentation. (User guide)
All you do is install mdac downloadable from Microsoft.com, or any MS
product like Office. Than run odbcad32.exe to set your DSNs. that's
it, works like a charm and is the only known way to man to connect to
an MSSQL server from Unix.
After you install MDAC, you can also install Oracle's drivers for
windows but that is a bit more tricky, just like on windows.
Also search archives it was there before.

Free Life
Boaz

Re: STLPort 5.1 and winegcc / winelib

[Boaz Harrosh]

[EMAIL PROTECTED] wrote:
> I was wondering if anyone had tried STLPort 5 with winelib. From searching 
> the archives it seems you need to swap out gcc/c++ for winegcc/wineg++ and 
> pass the -mno-cygwin option. Doing that gives me these errors. 
>
> make -f gcc.mak all
>
> wineg++ -pthread -mno-cygwin -fexceptions -fident  -fPIC -O2 -fuse-cxa-atexit 
>  -D_REENTRANT -D_GNU_SOURCE -I../../stlport  -c -o obj/gcc/so/dll_main.o 
> ../../src/dll_main.cpp
> /usr/include/../include/stdlib.h:469: error: expected ‘;’ before ‘*’ 
> token
> /usr/include/../include/stdlib.h:470: error: expected ‘;’ before ‘*’ 
> token
> /usr/include/../include/stdlib.h:471: error: expected ‘;’ before ‘*’ 
> token
> /usr/include/../include/stdlib.h:475: error: expected ‘;’ before ‘*’ 
> token
> /usr/include/../include/stdlib.h:479: error: ‘int32_t’ has not been 
> declared
> winegcc: g++ failed.
> make: *** [obj/gcc/so/dll_main.o] Error 2
>
> Anyway these are probably from grabbing the system headers which I have read 
> you should not have happen, but if I try to use a 
> -isystem/usr/include/wine/msvcrt or -Isystem/usr/include/wine/msvcrt and 
> -nostdinc++ you then get tons of errors about the stl headers missing 
> exception, cstring, etc. I was wondering if anyone had any thoughts or ideas 
> on how to get this compiled so it is usable is porting applications.
>
> Thanks
>
>
>
>   
look at, and download from: http://sourceforge.net/projects/onesource/
(If you use KDE it has a phantom folder inside watch out)

You will see an STLport folder and a wine\include\msvcrt folder and also
the Makefiles.
This is all very old, pre-winegcc. STLPort 4.6.x, but the principle is
there. A wine.mac for STL to compile over msvcrt from wine, a config.h
or what ever it is I can't remember. And the most important is
"typeinfo" and "new" header files in wine/include/msvcrt.

I can hardly remember all the details but in principle. Configure
STLport to use all it's internal implementations (see wine
stlport-config files inside). And like you tried, don't let GCC use any
of it's headers. Than the only missing headers will be "typeinfo" and
"new". Also I think I had to play with include path a bit, or put some
headers in stlport/include that include other headers of same name from
wine. It did work at the end, let the compiler guide you. Also look back
in 2004/2005 archives I remember I had a much more detailed description
of what to do exactly. Search for "stlport". (You are not the first one
that asks)

Please note:
- wine headers are very old, use new wine headers with what ever is
missing from my zip file.
- the "typeinfo" and "new" files are basically the GPLed files from GCC
a bit modifies so they compile. See if you need to do it again to newer
GCC files, what ever the GCC version you have.
- Some more headers can be found at msvc/include folder that had a bit
of magic to glue every thing together, but that was more for MFC and ATL
stuff, I'm not sure STLport needed any of that. I think you need MBCS
defined for msvcrt to have all that STLPort needs.

Free Life
Boaz

Re: STLPort 5.1 and winegcc / winelib

[Boaz Harrosh]

[EMAIL PROTECTED] wrote:
> I was wondering if anyone had tried STLPort 5 with winelib. From searching 
> the archives it seems you need to swap out gcc/c++ for winegcc/wineg++ and 
> pass the -mno-cygwin option. Doing that gives me these errors. 
>
> make -f gcc.mak all
>
> wineg++ -pthread -mno-cygwin -fexceptions -fident  -fPIC -O2 -fuse-cxa-atexit 
>  -D_REENTRANT -D_GNU_SOURCE -I../../stlport  -c -o obj/gcc/so/dll_main.o 
> ../../src/dll_main.cpp
> /usr/include/../include/stdlib.h:469: error: expected ‘;’ before ‘*’ 
> token
> /usr/include/../include/stdlib.h:470: error: expected ‘;’ before ‘*’ 
> token
> /usr/include/../include/stdlib.h:471: error: expected ‘;’ before ‘*’ 
> token
> /usr/include/../include/stdlib.h:475: error: expected ‘;’ before ‘*’ 
> token
> /usr/include/../include/stdlib.h:479: error: ‘int32_t’ has not been 
> declared
> winegcc: g++ failed.
> make: *** [obj/gcc/so/dll_main.o] Error 2
>
> Anyway these are probably from grabbing the system headers which I have read 
> you should not have happen, but if I try to use a 
> -isystem/usr/include/wine/msvcrt or -Isystem/usr/include/wine/msvcrt and 
> -nostdinc++ you then get tons of errors about the stl headers missing 
> exception, cstring, etc. I was wondering if anyone had any thoughts or ideas 
> on how to get this compiled so it is usable is porting applications.
>
> Thanks
>
>
>
>   
look at, and download from: http://sourceforge.net/projects/onesource/
(If you use KDE it has a phantom folder inside watch out)

You will see an STLport folder and a wine\include\msvcrt folder and also
the Makefiles.
This is all very old, pre-winegcc. STLPort 4.6.x, but the principle is
there. A wine.mac for STL to compile over msvcrt from wine, a config.h
or what ever it is I can't remember. And the most important is
"typeinfo" and "new" header files in wine/include/msvcrt.

I can hardly remember all the details but in principle. Configure
STLport to use all it's internal implementations (see wine
stlport-config files inside). And like you tried, don't let GCC use any
of it's headers. Than the only missing headers will be "typeinfo" and
"new". Also I think I had to play with include path a bit, or put some
headers in stlport/include that include other headers of same name from
wine. It did work at the end, let the compiler guide you. Also look back
in 2004/2005 archives I remember I had a much more detailed description
of what to do exactly. Search for "stlport". (You are not the first one
that asks)

Please note:
- wine headers are very old, use new wine headers with what ever is
missing from my zip file.
- the "typeinfo" and "new" files are basically the GPLed files from GCC
a bit modifies so they compile. See if you need to do it again to newer
GCC files, what ever the GCC version you have.
- Some more headers can be found at msvc/include folder that had a bit
of magic to glue every thing together, but that was more for MFC and ATL
stuff, I'm not sure STLport needed any of that. I think you need MBCS
defined for msvcrt to have all that STLPort needs.

Free Life
Boaz

Re: Winlib - Active Scripting

[Boaz Harrosh]

Luc-Eric Rousseau wrote:

thanks.
Are there any known issue with the native microsoft WSH (Windows 
Scripting Host)DLL under wine? Has this this been done with a WineLib 
app in the past?
  
Yes I have used it under IE under Wine including direct access from a 
C++ program. It worked fine. I had Ole98 and IE6 native installed. But 
that was long time ago it might work with out these two.


Free Life
Boaz

Re: winnt32.exe on AMD64

[Boaz Harrosh]

Ge van Geldorp wrote:

From: "Nadgir, Ananth P" <[EMAIL PROTECTED]>

Does Wine now support executing x64 bit PE executable like 
winnt32.exe under amd64 directory?



No, the biggest problem is that the 64-bit calling conventions are different
between PE executables and Linux executables. Some more info on the Wine64
wiki page http://wiki.winehq.org/Wine64

Ge van Geldorp.
  

Which brings me to an Idea I had a long time ago.
 Why not compile the all of Wine as PE with a GCC cross-compiler 
(MinGW), But for the 3 low level DLL's. In effect a ReactOS system and 
Makefiles (On a Linux kernel). Sure we will maybe want an alternate 
system for Builtin/Native, maybe different system folders for  builtin 
dlls and executables vs. native. This will surely solve the Above 
problem. It will also make a clear cut of what are Wine DLLS that are 
the same for Wine/ReactOS and what are System dlls that are 
System/Kernel dependent. It will avoid the problems with export 
functions and so on ...


Has any one (ReactOS?) tried such a system on Linux? What is the minimum 
dll set that must be compiled ELF?

Does MinGW (gcc for PE) has support for Win64?

(And a philosophical Question: The "Sameness" of 32 bit calling 
convention (and virtual tables) between PE and lets call it GCC, was 
that a freak of nature? or is it just that Unix people got there first 
this time and MS people must be cocky? Or was it the Unix People who got 
cocky this time? ;-)


Free Life
Boaz

Re: winnt32.exe on AMD64

[Boaz Harrosh]

Ge van Geldorp wrote:

From: "Nadgir, Ananth P" <[EMAIL PROTECTED]>

Does Wine now support executing x64 bit PE executable like 
winnt32.exe under amd64 directory?



No, the biggest problem is that the 64-bit calling conventions are different
between PE executables and Linux executables. Some more info on the Wine64
wiki page http://wiki.winehq.org/Wine64

Ge van Geldorp.
  

Which brings me to an Idea I had a long time ago.
 Why not compile the all of Wine as PE with a GCC cross-compiler
(MinGW), But for the 3 low level DLL's. In effect a ReactOS system and
Makefiles (On a Linux kernel). Sure we will maybe want an alternate
system for Builtin/Native, maybe different system folders for  builtin
dlls and executables vs. native. This will surely solve the Above
problem. It will also make a clear cut of what are Wine DLLS that are
the same for Wine/ReactOS and what are System dlls that are
System/Kernel dependent. It will avoid the problems with export
functions and so on ...

Has any one (ReactOS?) tried such a system on Linux? What is the minimum
dll set that must be compiled ELF?
Does MinGW (gcc for PE) has support for Win64?

(And a philosophical Question: The "Sameness" of 32 bit calling
convention (and virtual tables) between PE and lets call it GCC, was
that a freak of nature? or is it just that Unix people got there first
this time and MS people must be cocky? Or was it the Unix People who got
cocky this time? ;-)

Free Life
Boaz

Re: [TOOLS] Re: Gecko installer

[Boaz Harrosh]

Jeremy Newman wrote:

This is now live at:
http://source.winehq.org/winegecko.php

  

This is grate!
 It is Based on SeaMonkey version 1.8.0.1. We might want to do some 
kind of version system, this thing gets updated pretty fast, security 
updates and stuff...


By the way, How do you make a CAB file is there a free tool to make it? 
or is it Just a renamed ZIP file?


Free Life
Boaz

Re: Gecko installer

[Boaz Harrosh]

Jacek Caban wrote:

Hi.

Please consider this mail as:

Re: Built-in iexplore
Re: acad 2004 licence file bug
Re: Broken FC5 packages - stay clear.

Last week Wine Gecko was mentioned a few times on this mailing list 
and I can see that there is no understanding of it. It's not really 
surprising as it's a big mess ATM. We can still use Mozilla ActiveX 
control (but that needs to be removed) or (xor) directly Gecko. 
Sometimes  (if the app uses HTMLDocument directly, not via WebBrowser, 
like iexplore does) only the second option works. That has led me to 
do what I am planning to do later. I've just sent Wine Gecko 
installer. After it will be committed, a system similar to Mozilla 
ActiveX control download will have to be set up (that is upload the 
package to SourceForge and add a script that directs download of it). 
That will allow us to get rid of Mozilla ActiveX control.


Thanks,
   Jacek

Hi Jacek.

This would maybe also Address my problem. Please see my posting this 
week [Wine's Mozilla Control - Very old]

Please I have a few Questions:
- Are you intending to produce a PE Gecko installer maintained by you or 
are you using a ready made package?
- Will this package be updated from time to time when Gecko is updated? 
and kept as current as possible?
- In theory, do you think your implementation when finished could be 
replacing the "Mozilla ActiveX control" on windows (and ReactOS). I 
don't think you will have any problems with DLL names since Windows can 
be made to load local DLL's first. Any way a Makefile hack could be made 
to change the names. You will, however, need an alternative GUID for 
windows if needed to run alongside IE.
- Will/are you in contact with Mozilla.org people to support us in this 
task. (Updates, chromes, settings, plugins ...)
- Will you have a browser-like application along side this installation 
to let users maintain their gecko engine. (Updates, chromes, settings, 
plugins ...)


I have attempted a bit of this task based on SeaMonkey but I have come 
to the conclusion that I'm not up to the task. Too many if(s) that I 
don't have the answer to.



There is this site  which 
is the Official site for the Mozilla activeX Control. It looks like it 
as stopped maintaining the Control. The only availability of the 1.8 
version of Gecko and the Control is in SeaMonkey. I have written Adam 
Lock a short e-mail asking on the project status, yesterday. I will keep 
you posted on his response. (??)


Mike wrote ...

> A native Linux copy of Gecko installed as part of, say, the 
distributions Firefox?


Please note that Firefox distribution according to Mozilla documentation 
(See FAQ on link above) is not good because the Gecko is statically 
linked and cannot be accessed from outside. The only Project that can be 
used with current Gecko is SeaMonkey. (I may be wrong about Linux-Gecko 
but I suspect they have the same problems as on Windows. dynamic-linking 
load speed)


It looks like all kind of people are looking for a Gecko SDK-kind 
package. I did not find any. If any one knows of one please tell me.


Free Life
Boaz

Wine's Mozilla Control - Very old

[Boaz Harrosh]

For any it might concern!

The Mozilla ActiveX Control recommended for download by Wine is based on 
a pre FireFox 1.0 gecko engine and is missing support for many web 
standards!


I was doing development in Windows and needed an Embedded browser. I 
wanted to also support Mozilla engine and was Quickly downloading the 
ActiveX from wine download page. (My installed FireFox does not supply 
one). My work involved embedding the FCKEditor 
(http://FCKEditor.sourceforge.net). So I installed and change the source 
code to use the Mozilla GUID and oops FCKEditor does not work.


After some investigation I found that even though the Control's package 
is from Q4/2005 the engine included is much older and belongs to Mozilla 
1.6 or something. Since then the Mozilla package did not include a new 
Control and Has eventually stopped been released. (Do to FireFox 
replacing it).


The New (Mozilla 1.8) Control can only be found in the new SeaMonkey 
1.0.x package, which is what I got. And with this control every thing 
works grate. (Even better than IE). Now SeaMonkey 
(http://www.mozilla.org/projects/seamonkey) is a very large package and 
is not something a user would be Happy to be forced with. I did Package 
a one time Installation of the new Control, stripping down from 
SeaMonkey anything I could guess does not belong. But this is a one time 
Job and I'm not sure is the right solution. Maybe we should contact the 
Sea-Monkey maintainers and ask them to Also produce an "on the side" 
extra package for our sake. I have not done that yet ... Any body in 
contact with Mozilla.org?


Free Life
Boaz

Re: World of Warcraft (WoW) patch/more address space layout stuff

[Boaz Harrosh]

Mike Hearn wrote:

It's a bug in WoW itself, it relies upon the exact way NT maps memory
which is different to how Linux does it. I guess they are storing
information in the high bits of a pointer somewhere or some similar
trick.

One can never be sure, but I suspect this is not do to a bug but to a 
fixture.
WoW Has a all chain of checks that go up all the way to rootkit reveler 
to make sure the user is not aided by an automatic system, Given the 
player an advantage  other players do not have. The Memory layout checks 
is for making sure the program is not loaded by a Debugger of sorts. Or 
that core Dll(s) where not replaced/hooked/emulated.


It is possible that approaching Blizzard might be helpful. Is WoW 
supported by Cedega?


Free Life
Boaz

Re: SoC: wince apps on arm

[Boaz Harrosh]

Stefan Dצsinger wrote:

Am Samstag, 20. Mai 2006 23:13 schrieb Hבmorszky Balבzs:
  

it should be nice to make wine run on arm pda-s and run wince apps.
It could be a real good thing for linux on any pda and smartphone...
i think.


First of all, I'm not an wince expert, so this could be wrong.

If I remember correctly, this has been brought up before, and the problem is 
that wince and normal windows are way too different for that to be possible. 
Although some code could be shared, enabling wince apps on wine would almost  
mean re-implementing wine.


Stefan
  




  
I was the one that looked into it. It is not at all a re-implementing. 
It is only the places of functions that change. meaning, it is the same 
API but functions sit in different dll(s) So the all make system and 
spec files change. Also some tweaking to the loader.
ReactOS was able to run minimal WinCE application as is. There is a 
minimal skeleton of wincedll.dll over on ReactOS subversion. One thing 
that is not clear is the exceptions mechanics, memory layout, and maybe 
a wineCEbuilder too, but not necessarily.


So no. it is not a re-write. M$ did a rewrite but it does not mean it is 
a must. I would say it is an effort in par with a Wine-on-OSXx86.


Free Life
Boaz

Re: Wine as Windows Terminal Server?

[Boaz Harrosh]

Samuel Hunt wrote:

Thought for you all.


Would it be possible to use Wine with a few extra bits to make a kind 
of Windows Terminal Server?


So you login via VNC, and the Wine system prompts you for a username 
and password, which it authenticates. It then loads up a "desktop", 
with a fake "Start" menu, that you have things similar to a normal 
start menu, but more appropriate to a terminal server environment.


You then run your programs, but all the I/O is to/from the remote 
client, and each session is independent of each other, so there can be 
lots of different clients with different permissions (so admin may 
have full access to all of the drive, but users have various bits of 
their "hard drive" read-only and things like that).




Would seem to make Wine very useful if that could be done. Then VNC 
clients simply see a "Windows" desktop, and can do what they want, but 
all the back-end is Wine and Linux.



Sam




I have done something similar but with the X11 protocol.
The client user browses to a web site (somewhere on the LAN). He than 
gets a Menu of applications /Sessions he can use. If these clients are 
Linux than no problem an ssh-X session is initiated to open that 
application. ( We used a load balanced collection of servers). If it was 
a Windows Client than first time comers get an OCX installed that in 
turn installs XMing X-Server and plink. Once installed, the web page 
will initiate the same ssh-X session as before. We chose remote 
application to run as Native apps so there is no distinction between 
locally running or remote applications. But a desktop mode can be used 
as well.


One thing to watch out is that: Currently, wine does not support 
multiple X connections on the same WineServer. What I did is use the ssh 
connection environment variables and set up a quick on-the-fly wine 
$WINEPREFIX folder for each new session. This gave me a nice Cytrix like 
control over what gets saved during a session. (Which was nothing in our 
case)


Remoting is nothing new to Linux, and VNC could work Just as well. Wine 
is just a regular X-client application. Anything that applies to a Linux 
application also applies to a Wine application running under Wine.



Free Life
Boaz

Re: Wine 0.9.9 and instalation of AutoCAD 2000

[Boaz Harrosh]

Vitaliy Margolen wrote:

Please submit bug reports to http://bugs.winehq.org/ instead of sending
e-mails here.
  
Bug report aside, he is a developer and he wants to fix this. What he's 
asking is if any one remember an issue concerning: "map_image Section .rsrc"

Re: Winelib

[Boaz Harrosh]

Michael King wrote:

Troy

Thanks for your comments. The issue with using a 'script' file versus a true 
'executable'
is really a matter of marketing.

  


Than you'll have to do like my father did. ;-)
Look in the source tree, You'll see that wine is just wineloader and the 
real wine is wine-kthread/wine-pthread. Hack on wineloader, first call 
it what you like than you can hard-code the Winlib to load. Don't forget 
to force WINEPREFIX to your installation so it will not conflict with 
the user's regular wine. And the source to that "Mywineloader" will have 
to be served with code. (LGPL)


Free Life
Boaz

Re: Repackaging Mozilla ActiveX control to include MSVCP60.DLL?

[Boaz Harrosh]

Hi! I was Just wondering. Is there at all a MinGW build system for the 
"Mozilla ActiveX control"? I guess not so the Question is:
Any body knows what are the Main hurdles for that? Is that mainly COM 
TLB(s) related? or there are other problems?


Ge van Geldorp wrote:

From: Dan Kegel

The Mozilla ActiveX control download feature is cool and all, but 
until we repackage the sucker to include MSVCP60.DLL to fix

http://bugs.winehq.org/show_bug.cgi?id=4064
it's going to leave a lot of users scratching their heads as to why it 
keeps asking where its files are.


I could have sworn I saw somebody post a note saying they had done 
said repackaging, but I can't find it now...



http://www.winehq.org/pipermail/wine-patches/2005-December/022795.html
Instructions on how to repackage can be found at
svn://svn.reactos.org/trunk/tools/MozillaControl/

GvG




  

Re: Question regarding the Wine Vs WineLib performance

[Boaz Harrosh]

What are the timing for the three classes ?

Ananth M wrote:



On 1/5/06, [EMAIL PROTECTED] 
* <[EMAIL PROTECTED] 
> wrote:



Thank you !!

I will try to compile the windows application using MinGW and check 
the performance using the same DLL.


Here is the some more information that I would like to share with you  
is :
 I am using the Binary only DLL. I am not having the source for the 
DLL. SO I am not compiling the DLL in windows or in Linux. I am 
linking this binary only dll with my windows application, (since my 
application uses the function exported by this binary only DLL)
Then I moved the executable to Linux and executed using the wine 
.
I checked the execution time of  the function exported by the Binary 
Only DLL


In the second Case , I created the .so for the binary only dll, such 
that the functions that are exported by the binary only dll will be 
called from the stub functions exported by the .so
Then I called the stub function (exported by .so)  from my winelib 
application.
But, In this case  also, I checked the time duration for the execution 
of the dll function only.( by adding a code that gives the time 
duration, in the stub function that calls the dll function).


As a third Case, I loaded  the binary dll directly (without creating 
the .so),  using LoadLibrary ("Binaryonlydll"),  and compiled and 
linked the application using Wine supplied DLL's and header files. 
Then I called the function exported by the binary only dll directly 
from the application  and checked the time duration for the execution 
of  the dll function .


In this case also we are  getting the same timing as in Second Case, 
but we are not getting the better performance as in first case.


 
 
 






  

Re: issues compiling ReactOS newdev on wine

[Boaz Harrosh]

Mike McCormack wrote:



Secondly, what the whole story with WCHARs? Why do
L"Unicode string" type strings work in wine apps but
not in winelibs?


Some compilers do not support L"string".  Older versions of gcc assume 
a wide character is 32 bytes, not 16.  For compatibility with those 
older compilers, we are restricted to using array initializers for 
WCHAR strings.



In my opinion this is most unfortunate.
1. These Older versions of ... are none existent. I have never actually 
encountered them. Say I, some one that has one actually used.
2. It should take 10 minutes to write a Perl (/pick your script) script 
that pre-parses the code and changes any occurrence of above to arrays. 
And if it is slower than the user can take the time and do 3.
3. If a supported platform is identified that absolutely does not 
support compilation of 16-bit chars. We can make available gcc patches 
that do.

4. ./configure should check for it and add the proper make magic
5. winegcc since it was compiled with the same compiler can make it all 
automatic.


But in no way do I see why we have to throw away good code for bad one. 
Why do a compiler job?



Free Life
Boaz

Re: Debugging winelib apps in Eclipse

[Boaz Harrosh]

Michael Ost wrote:
Does anyone know how to set up Eclipse to debug winelib applications? 


I tried just replacing 'gdb' with 'winedbg' on the "Debugger" tab on the
"Debug" window. After Eclipse says "Launching..." there is an error that
says "Process terminated." 


After reviewing the winelib debug docs, I found that there is a --gdb
switch to winedbg so I added that as a "C/C++ Program Argument" on the
"Arguments" tab of the same window... a long shot, and it didn't work.

This is on Fedora Core 4, with Eclipse 3.1 (yum updated from the 3.1M6
version that comes with FC4), and with the wine 0.99.2 FC4 rpm.

Any leads? Thanks ... mo
  
There is no need to use winedbg for a winelib application. The only 
advantage for that is the heap-walk, thread-walk and other special 
winedbg commands that will be hard to reach from the GUI. The 
disadvantage is that it is not compatible enough and breaks the GUI.
Just use gdb it can understand all your symbols and wine's. What you 
need to do is run wine-kthread or wine-pthread directly. Check in your 
ps when you run a wine application what actually loads.


Free Life
Boaz

Re: popen() to execute\read a Linux (not windows) command

[Boaz Harrosh]

Eric Pouech wrote:

Boaz Harrosh wrote:


Such a program could also be useful for a Native app that needs to 
run a Linux application.


we should even try to integrate it to popen in builtin msvcrt
A+
What do you mean? with a check for a "special" app_name. Or an 
auto-detection of the binary and delegation to (g)libc - popen? And 
bridge of Wine-std-I/O to Linux-std-I/O.


I thought about it a bit, The I/O bridging will have to be either done 
with threads, or with async I/O in Read/WriteFile and accept on the 
Linux side.


Free life
Boaz

Re: popen() to execute\read a Linux (not windows) command

[Boaz Harrosh]

Sergio wrote:

I see. But I need to link to msvcrt for the rest of the functions in the dll
I am trying to make. I only need popen to be linked using linux' libraries.
Do you know what I can do to have both things (standard popen and wine's
libraries for the rest of the dll)?
  

A second dll maybe. (That is not liked to msvcrt)

Also one more thing you could do is a small Winelib app 
(run_unix.exe.so) that communicates STDIN STDOUT raw style through 
GetStdHandle / ReadFile /WriteFile (see MSDN). and in tern popen() a 
Linux process. So you do:



   popen("run_unix param1 param2 ..." ,"rb+") ;


Such a program could also be useful for a Native app that needs to run a 
Linux application.


Free Life
Boaz

Re: wine and automation objects

[Boaz Harrosh]

Curro Amores wrote:

hi,

I have an application with Access 97 and i use automation for some 
aspects.
The app runs perfectly but when i want to do something that uses 
automation it crashes.


Anybody could help me?

thanks

maybe it will work with Native OLE implementation. If you must use it 
Install dcom98


Free Life
Boaz

Re: winedbg and ddd/kdbg problem...

[Boaz Harrosh]

Eric Pouech wrote:


that didn't change. This would require gdb to know about .pdb, which 
it doesn't. in the long run, it may be easier to get windbg handle 
properly elf/{stabs|dwarf} information, rather than the other way around.

A+


From passed experience, I have found that for Winelib, or Plain Wine 
debugging, I get the same results with Plain gdb. Or in my case 
KDevelop. (No need for Winedbg at all)


For GUI .pdb debugging I have made some attempts to run Winedbg directly 
under KDevelop. As KDevelop Just pushes commands into gdb's stdin and in 
return parses stdout, With some relaxing of the parser code, I was able 
to get the stack frame and disassembly windows. This is do to the fact 
that Winedbg tries to keep the commands the same as gdb, and the output 
used to be similar as well. The more advanced stuff like setting 
breakpoints and watch variables failed miserably. But I was able to do 
those on the command prompt KDevelop provides as low level interface to 
"gdb". I was on my way to go in deeper and fix the C++ source debugging. 
Again by making the parser relax on the Winedbg output formating, but 
the Project canceled, and I never got to it. Since than Winedbg was 
completely changed, and I never attempted the same thing again.


Free Life
Boaz

Re: winedbg and ddd/kdbg problem...

[Boaz Harrosh]

Eric Pouech wrote:
- in my case, the source code doesn't show up alone. I use the 'show 
code' button in the breakpoint window
Is that gcc-elf-Linux code only like before? or is it possible now to, 
also see PE (.pdb) debugging info?


Thanks Boaz

Re: Resource file and linking C++ project using winelib

[Boaz Harrosh]

Sergio wrote:

My problem was that the MainDll function in the source lacked << extern "C"
  
Now my question is: how's it that VC++ did not need that?



  

Yes.
VC++ Has special handling for DllMain,WinMain and such. Depending on the 
different targets you have (MFC COM C and so on) there is different 
things going under the hood. Same as "main" for g++.



Free Life
Boaz

Re: Test If Running Under Wine

[Boaz Harrosh]

Craig macLeod wrote:

I have some code to test for the existance of explore.exe and if not 
present then assume we are under Linux. Is this sufficiently generic?


I think that is best. Since you are looking for the specific missing 
fixture, that could be fixed in future versions/Installations. Also you 
might consider suppling with your application installation a most simple 
"explorer.exe" that does exactly what you need. If it is to display a 
folder, look in codeproject.com they have a sample. Contact me off list 
I have a couple of hours work on top of that sample.


Free Life
Boaz


(foreign languages etc)


I've looked and did not find other names for it. 
%SystemRoot%\explorer.exe is probably it.

You also have the shell= in registry but that is not Necessary it.
also you have the public Window class: ExploreWClass => EXPLORER.EXE 
(look in MSDN)


Free life
Boaz

Re: headless question, and IPC question

[Boaz Harrosh]

Ken Larson wrote:


Thanks for the info.

Ultimately, my app is a Java app. 


If I recall correctly someone has reported Installation of Sun's Java 
for windows under wine. Or was it A failure to install? I can't recall. 
How would you call a DLL on Windows?


Free Life
Boaz

Re: headless question, and IPC question

[Boaz Harrosh]

Ken Larson wrote:

This assumes that I'm using winelib, correct? (I currently am not, I'm 
compiling on windows, but considering using winelib instead)



Yes!! Winelib can be both your DLL calling code, and you complete Linux 
application. No need for .EXE compiled or crosscompiled for windows, No 
need for IPC and no need for two parts at all.

I apologize for the State of the documentation that this is not clear!

It as been proven that any windows code can be compiled as Winelib. If 
you are using core Libraries like MFC or ATL than that might get 
difficult (not impossible), but it seems this is not your case. On the 
other hand Winelib applications are a Linux applications so they can 
link to any Linux library. Just that they have a funny Makefile and are 
built with Winegcc.


Statically linking of a DLL is done as follows:
- Write a .spec file prototyping your DLL, than “winebuild” it to a .DEF 
file. (make a rule for it in Makefile)
- Link your Winelib against that .DEF file like you do any other 
Wine/Native DLL.


.spec file syntax is documented and should be simple. Now all this is 
easy if your DLL is extern "C". If it is C++ exports you'll need 
something extra. Is your DLL exporting C++ mangled symbols?


Free Life
Boaz

Re: Windows CE on Wine

[Boaz Harrosh]

On 9/20/05, Filip Navara <[EMAIL PROTECTED]> wrote:


It was proved that to run simple WinCE/x86 programs all that is
needed is to get the loader to accept the WinCE PE signature (which Wine
used to ignore and probably still does) and have implementation of the
DLLs...
   


Was that on React-OS or on Wine?

Steven Edwards wrote:



I had to flip the subsystem ID of a WinCE test app using one of the
msvc build tools. My sample application just called a message box api.
I don't know if any more complex WinCE applications would work due to
threading and memory management differences.
 

OK Exactly! At first I did not think we could use the same binaries. 
Just maybe the same codebase but compiled with different set of 
makefiles. I'm not even sure the ABI is the same. The sameness is only 
promised at the source code API level.


 Funny how Microsoft uses a totally different set of Headers for CE. 
Even the Wine-headers are closer to the original SDK than CE. The order 
of function is different, the macros, the styling. There is no 
resemblance, not even one name of one parameter. Just the Function name 
and the Header name. Its like they had a copyright problem and needed to 
write it from scratch.:)
 Now for wine I will not do the same. I'll try to keep the same 
headers, and where there are ABI differences. Like calling convention 
parameter sizes.. I'll try to use a macro.
 On the implementation side Linux is Linux is Linux so I guess that 
should work well. But it looks like The Win32 API was shifted around a 
bit so in CE functions don't sit in the same Dll's as they sit in Win32, 
and apps are linked differently. So spec files and Makefiles will have 
to be different.


What I'm afraid of is the things I don't know, which is how x86 is Wine. 
And how separated is that from the rest of the code.


Thanks guys
Boaz

Windows CE on Wine

[Boaz Harrosh]

OK What you guys think.

I have an Arm based machine Running Windows CE. Same machine also runs 
Linux...


Do you think it can be the same Wine codebase, implementing Both Win32 
API as well as WindowsCE API?


What areas must be rewritten (or not) ?
 1.Loader
 2.HAL (is there an HAL in Wine)
 3.Debugging / exceptions

any thing else? Other CPU(s)?

What if I want to do the same but for WindowsCE x86?

Free Life
Boaz

Re: Delphi 5 debugger is working!

[Boaz Harrosh]

Vitaliy Margolen wrote:


As of todays CVS Delphi 5 debugger is fixed.


Unfortunately fixing NtQueryVirtualMemory, NtProtectVirtualMemory and others
is not that simple. Basically there are no way to do it from other processes.
Ok, NtQueryVirtualMemory could be implemented some-what easily using
NtReadVirtualMemory and possibly one more server call. But for others I see only
 

How does gdb do these things to a Linux process? I would think a 
Debugger should have such services from the Linux Kernel. Is not the 
Delphi debugger a Debugger through the debug services Wine implements? 
(dbghelp and friends)


Free Life
Boaz

SMB for FUSE

[Boaz Harrosh]

*Is anybody familiar with this project?:
SMB for FUSE 



It looks like a way to send users who need (Semi-transparent) UNC 
support. I was thinking of linking the .wine/dosdevices/unc to the above 
mount point.

**
Free Life
Boaz
*

Re: Inconsistency/bug with GetProcAddress

[Boaz Harrosh]

Mike McCormack wrote:



You might be able to do it by staticly linking ntdll, kernel32 and 
user32 with wine-pthread/wine-kthread, and fixing the binary's address 
in memory, though that would probably be quite a bit of work.


Mike


This is not a bad Idea for other stuff as well one thing that comes to 
mined is winlib (self contained package). Though I admit I am not that 
brave.
What would you do? a configure switch with alternate make targets. Could 
you think of a way that would get accepted into the tree and be 
regularly tested for?


Free Life
Boaz

Re: Bug in native user32

[Boaz Harrosh]

Filip Navara wrote:



Maybe it's just me, but I thought this is well-known "feature" of the 
API. It's implemented in ReactOS for quite some time. *g*


- Filip


Yes! but the headers, are they fixed? What do you do in react OS do you 
have 2 different definitions for RegisterClassExW


Free Life Boaz

Re: include/msvcrt/crtdbg.h

[Boaz Harrosh]

Saulius Krasuckas wrote:


It seems I was too in hurry.  Some comments follows.


* On Tue, 19 Jul 2005, Saulius Krasuckas wrote:
 


int   <->  long int.
void (*)  <->  void (__cdecl *_CRT_DUMP_CLIENT) (void *, size_t)
   



I mean differences between native version and a Wine's one.

 


Then I see all the declared function are defined to be non-operational:

| #endif /* _DEBUG */
| 
| #define _CrtCheckMemory()   ((int)1)

| #define _CrtDbgReport(...)  ((int)0)
| #define _CrtDoForAllClientObjects(f,c)  ((void)0)
| #define _CrtDumpMemoryLeaks()   ((int)0)
   



These are defined in the Wine tree.  They are out of the #ifndef _DEBUG - 
#else - #endif statement, so they make inclusion of a header file 
impossible.


Definitions should be transfered into two parts:  operational (_DEBUG 
defined) and non operational (no _DEBUG defined).  Right?


 

Yet then I see lots of declared functions are prefixed with __cdecl and 
_CRTIMP prefixes.
   


 ...
 


| #define _CRTIMP __declspec(dllimport)
   



And that comes from native header file.  Should we do the same in the Wine 
header?


Maybe someone is working on this already?


 

 Not many apps (source code) use these functions. Mainly MFC and 
ATL/WTL and derived applications.
If it is the later case (MFC/ATL) than one can just get native header 
together with where he gut MFC/ATL from, and just make sure that it is 
in a folder with higher precedence than wine's. It will compile.
 If your code can make do without MFC/ATL and only thing missing is CRT 
memory debugging tools, than you can go head and implement them. (Or use 
native msvcrtd.dll which is of the same license as crtdebug.h. Debug 
version is of a different license than release)
 What I've seen done by people is Leave these off, as wine is doing 
now, but use other (gcc type tools) compiled into wine to debug memory 
leaks. Was that Valgrind (http://valgrind.org/) or something? See list 
archives for instructions how to use it.


Free Life
Boaz

Re: pointer to __cdecl function

[Boaz Harrosh]

Saulius Krasuckas wrote:


I am trying to sync w/ native crtdbg.h file, which defines:

| typedef void (__cdecl *_CRT_DUMP_CLIENT) (void *, size_t);

This doesn't compile with my gcc:

| gcc -c -I. -I. -I../../../include -I../../../include 
-I../../../include/msvcrt -I./..   -D_REENTRANT -fPIC -Wall -pipe
| -mpreferred-stack-boundary=2 -fno-strict-aliasing -gstabs+ -Wpointer-arith  
-g -O2 -o headers.o headers.c
| In file included from headers.c:35:
| ../../../include/msvcrt/crtdbg.h:52: parse error before '*' token

Does anyone know a way to workaround this?


 


I compiled native crtdbg.h with gcc 3.3.x Just fine.
with:
#define __cdecl__attribute__((__cdecl__))

what is the version of your gcc

Free Life
Boaz

Re: pointer to __cdecl function

[Boaz Harrosh]

Saulius Krasuckas wrote:


I am trying to sync w/ native crtdbg.h file, which defines:

| typedef void (__cdecl *_CRT_DUMP_CLIENT) (void *, size_t);

This doesn't compile with my gcc:

| gcc -c -I. -I. -I../../../include -I../../../include 
-I../../../include/msvcrt -I./..   -D_REENTRANT -fPIC -Wall -pipe
| -mpreferred-stack-boundary=2 -fno-strict-aliasing -gstabs+ -Wpointer-arith  
-g -O2 -o headers.o headers.c
| In file included from headers.c:35:
| ../../../include/msvcrt/crtdbg.h:52: parse error before '*' token

Does anyone know a way to workaround this?


 


I compiled native crtdbg.h with gcc 3.3.x Just fine.
with:
#define __cdecl__attribute__((__cdecl__))

what is the version of your gcc

Free Life
Boaz

Re: Serious Legal question - TLB(S)

[Boaz Harrosh]

Robert Shearman wrote:



 what complicates the matter for TLB files is that they contain 
variable names and comments/help strings that could constitute a 
copyrightable work. 


What if I do not extract comments/help and regenerate variable names, is 
it than OK.


Therefore, I would suggest that you could use the generated .idl file 
to write your own .idl file that has the same interface, but would not 
be considered a copy or derived work. This is similar to what is often 
done for Platform SDK header files in Wine. Naturally, once you have 
your own .idl file that is free of copyright restrictions you can do 
whatever you want with it, including (4 and 5).


Again, Must it be Human made or can I use a program that does all the 
above automatically? Is there in the law a distinct separation between 
Human hand made, or machine generated. Given that the output is the same?


Free life
Boaz

Serious Legal question - TLB(S)

[Boaz Harrosh]

Lets say I have an open source tool that I can compile with MinGW. That 
can open a COM DLL extract it's TLB and make an .IDL file out of it. 
Very similar to #import in msvc++ but to .IDL instead of a .H


Let's say I use this tool on a component of a Commercial program Like 
for example Norton Anti Virus. Or any other product and/or component. 
Let's say I am a legal user of this component.


Now what am I allowed to do with this .idl file: (??)

1. Nothing I must delete it and never do that again.

2. Use this idl to make a program that can interface that component, and 
I can also distribute such a program, as long as the user has a legal 
copy for that component.


3. I can use this idl to make my own implementation of that component. 
As long as I do not violate any patents on the way. And I can distribute 
that alternative implementation of that component.


4. I can Publish the component form 2 including the idl with an OSS 
compatible License.


5. I can Publish the component form 3 including the idl with an OSS 
compatible License


What do you guys think. A TLB in a DLL is that making things public?

Does any one know if this is at all addressed in EULA(s)? What does the 
law say if nothing is mentioned? what is the default? can I go up to a 
car Extract from the manual the size of the wheels and use third party 
wheels in it stead? Can I make My own cars that use the same wheels?


Free Life
Boaz

Re: Revisiting exceptions

[Boaz Harrosh]

"Jonathan Wilson" <[EMAIL PROTECTED]> wrote:
 

Why doesnt someone just implement the microsoft SEH keywords and extentions 
into GCC like it should be?
   

Do you have any knowledge of GCC, to be able to do it, or help me do it?
Dmitry Timoshkov wrote:
Because it's patented by Borland?
 

Do you have any reference to the patent? It looks to me like it is easy 
to by-pass by using different key words and than the user can Just 
define them to the MS ones.

Same with anything else microsoft that WINE or ReactOS needs (e.g. 
_declspec(thread) support)
 

Most of them are implemented at least in MinGW. Or have parallels that can 
easily be #defined too.
There is some work to do in porting the MinGW-PE stuff also for GCC-ELF, mainly 
dllexport/dllimport
Free Life
Boaz

Re: unix filenames in notepad

[Boaz Harrosh]

Troy Rollo wrote:
If it's too complex for *you* then nobody's asking *you* to implement it. It's 
needed for some uses of WINE, and we have at least one corporate developer 
and one individual developer who are willing to implement it. This pretty 
much guarantees something will be implemented whether it's beyond your 
capabilities or not. The only real question is what is the best *way* to 
implement it.

 

What I did is a solution totally out of wine. I changed the File-Dialog 
code to load KDE native, and use the Unix-2-windows Wine API(s) before 
calling the Win32 API. Same for a few Edit boxes that hold file paths. 
Inside was all Win32 only the highest GUI level was abstracted in a 
Class that hides it all. (Different file implementation in Makefiles). 
This and the Z: drive in setup and I was covered.
It is an outside wine solution. One could submit it as a Winelib only 
code. I cannot send my code as it is not Licensed to me, and any way it 
is in C++ and using a very strange GUI lib.

Free Life
Boaz

Re: Winelib's role in converting Windows applications

[Boaz Harrosh]

I totally disagree. It is like saying Lets not port. And keep paying the 
Microsoft tax. Which keeps Microsoft big and Linux small forever.
And is only good for PC. What about IBM machines, PDA(s), Suns, Macs... 
An x86 only Linux is not Principal-Linux.

The path is:
- Move to a different compiler on windows. Alternatives:
comu-c - (2 WML (Weeks for 1 million Lines) )
   C++ builder Borland. -  (Lots of COM ATL and MFC see MinGW. Lots of 
Win32API STL and C++ - 4 WML )
   gcc (MinGW)- (Very very soon - 6 WML )
   Intel c++- ( Don't know )

- Than Winelib on Linux. If you are using Technologies unavailable in 
Wine/Linux, (for example speech to text). Implement it and send patches 
to wine.
- Maintain the projects on all platforms (Including windows) with the 
same compiler and Makefiles.
- Slowly step-by-step Port MFC code to wxWidgets, STL to STLPort, ATL to 
Atilla, msvcrt to glibc ,Win32 to POSIX. And use POSIX portability tools 
on Windows.
- Stop the MS tax, grow up, get Independent.

You see Wine is like High-school where you get to Revolt against your 
parents. And it is like collage Where you get a real education. Than you 
have a real Job and you get to Fly rockets to the moon. But your parents 
can't come.

Free Life
Boaz
Ira Krakow wrote:
As many of you know, Brian and I are writing a book on
Wine and Winelib for Prentice Hall.  Brian's doing the
Wine part; I'm doing the Winelib part.
At Wineconf, I had a number of conversations about
Winelib's role in converting Windows apps.  The
consensus seems to be that the most efficient
conversion path is for much of the Windows app to stay
in Visual C++ (or whatever) and that only the modules
that specifically require native Linux calls should be
recompiled, via MinGW/Dev-C++ on the Windows side, and
Winemaker on the Linux side, into Winelib objects.  

For example, if the application requires PAM
authentication, or a Linux-based help system, these
modules would be separated out and encapsulated as
Winelib objects.  I was thinking of using PAM
authentication as a good example, since it works for
any authentication scheme that the application
requires.  

This is the approach I plan to take.  I welcome all
feedback.
Thanks.
Ira




 

Re: wineconf video downloads

[Boaz Harrosh]

Brian Vincent wrote:
fyi, I think this is what the files correspond to:
2005_04_30_10_12_39.avi Dimi 
2005_04_30_11_13_44.avi ???
2005_04_30_11_22_59.avi Charles Stevenson
2005_04_30_13_31_16.avi Juan
2005_04_30_14_00_31.avi Andrew Tridgell
2005_04_30_16_31_39.avi Andrew Bartlett
2005_05_01_08_52_15.avi ROS = Steven & Hyperion
2005_05_01_09_52_29.avi Jason E.
2005_05_01_11_12_30.avi Mike M. & Aric
2005_05_01_13_57_26.avi Marcus
2005_05_01_15_07_37.avi Paul & Jeremy W.
2005_05_01_16_48_07.avi Dimi #2

 

I haven't seen the videos yet (still downloading) but it looks like the 
main speaker is missing. No?

Re: InstallShield status page on the wiki

[Boaz Harrosh]

Mike Hearn wrote:
Dimi, the  tags don't seem to create any bottom padding like they would
normally so all the text seems squashed together even if they have
newlines between them. Can this stylesheet problem be fixed?
 

Dimi while you are at it:
I used :
   1. FCKEditor  or
   2. HTMLArea .
Last time I installed them on My Linux-Apache at home it took me 10 
minutes. Do have a look it makes Wiki life go to a different level

Free Life
Boaz

Re: Commercial support

[Boaz Harrosh]

Tom Wickline wrote:
Here is my proposal...
 

Must I shoot myself now or can I do it next week?  :) .

Put all Wineconf slides on Winehq

[Boaz Harrosh]

 For the sake of all the mis fortunate who could not attend Wineconf 
this year. Could someone, Please, collect all presentations and put them 
on Winehq. I thought that it could be nice if Wineconf page's "Agenda" 
could be updated to what it  actually was, with links from each session 
to it's slides, and if possible some commentary on important Q&A that 
arose.

Please ...
Free Life
Boaz

Re: How to format a IMediaSample?

[Boaz Harrosh]

Maarten Lankhorst wrote:
I'm having troubles sending a media sample over the graph,
I'm wondering wether that is because of the receiving filter or my own 
fault.

the thing I'm trying to send is a uncompressed 24 bit image, the 
bitmap info header data of it is pretty much as this:

mediatype: BI_RGB24
Width: 320
Height: 240
Bitcount: 24
Size of the image in bytes: 230400
compression: BI_RGB
so my questions about it are:
- What should I do with the ALLOCATOR_PROPERTIES
- What do I have to put in IMediaSample SetActualDataLength
- How can I fill the pointer returned by IMediaSample GetPointer so 
that the sample gets accepted?


You should/must grab DirectX9SDK from Microsoft and look into the code 
of DirectShow/baseclasses. What you are trying to do is actually long 
and tedious procedure that is almost impossible to explain. Even if you 
get it right with one Filter it might not work with the next filter. In 
principle there is a 2 stage, 3 steps each, negotiation between 2 
filters about the Allocator properties and  the Format header (it is 
actually even more steps) at the end if agreed, Not only the Format 
header is important but also some other properties of the Media sample 
object, and the Allocator object.

From what I understand from the License of this source, is, that you 
can use it to study and debug. What I suggest is that you compile a few 
of the Example filters in the SDK, than under Debugger  examine how they 
connect, than try them with your Filter and compare. You will have to do 
this on windows, probably with MSVC++. I was able to compile 
DirectShow/baseclasses with GCC, but there where bugs. Look at the tons 
of warnings, start with them.

Sorry if this sounds a bit as a discouragement. I have years of 
experience with Video filters and I still cringe to the taught of 
writing a video filter without DirectShow/baseclasses. I did want to, 
but never got to it, because it feels hard. But maybe you are not that 
far, maybe you are almost there, have a look under the debugger.

Free Life
Boaz

Re: Remote debugging

[Boaz Harrosh]

David Hemmo wrote:
But step doesn't work.
Would someone have an idea of where in wine source code I should have 
a look ?
Is there any document that you know that could help me to understand 
how it works, and the architecture ?

I do not know the answer, but I can add some info.
Both MSDEV6 installed under wine, and MinGW-gdb (Windows gcc) have this 
"step" problem. In Wine it is in the same place as on Windows. I think 
it starts in dbghlp.dll and than on NT it uses imghlp.dll and others. I 
am not sure what Wine is doing, but start from dbghlp.dll
If you can fix it it could be nice.

Free Life
Boaz

Autopackage 1.0

[Boaz Harrosh]

now that Autopackage 1.0 is out does any one plan on a Wine Autopackage 
installer.

Re: Rename the process back to wine on 2.6 kernels

[Boaz Harrosh]

Mike Hearn wrote:
This makes us appear as "wine" again on 2.6 kernels, instead of appearing as
/usr/bin/wine-preloader. It works in ps, top, and killall which are the most
important. On kernels that don't support it, we will still appear as
wine-preloader though.
If this patch is accepted I might do another to move the [pk]thread switch
into an env var instead of the command line. Then we'd be back to
"wine foobar.exe" just like the good old days ;)
 

A "not so far" back, there was a patch that enabled embedding of the 
wineloader into the Winelib stub of a Winelib application. (That would 
than load itself). How would that patch affect these applications?

Free Life
Boaz

Re: Attempt to make buttons themed

[Boaz Harrosh]

Frank Richter wrote:
Most interesting is probably to find out how the standard controls 
from user32 are themed. Poking a bit around in comctl32 6.0, it seems 
that it actually just registers the standard classes with 
RegisterClassW, nothing more. AFAIK you can't register a class when 
the class name is already used, so it would be interesting to know why 
comctl32.dll can get away with it.

Maybe it only register as per Process, which makes sense. And it does 
that before any window is displayed. Actually I know when. (A bug I had) 
it does it in the InitCommonControlsEx call. Not even in the DLLMain. An 
app that needs theming needs 3 things. 1. Link to comctl32 2. call 
InitCommonControlsEx and 3. a manifest. Right? So I guess you have it.

I'm not 100% but I think there is no need for duplicate code. All 
comctl32 needs to do is chain to the user32 classes, only overriding 
PAINT messages and some mouse events. So you don't have to reinvent the 
wheel.

Do you need lots of themed controls WM_PAINT code? Check out 
codeproject.com GUILIB project. They owner draw all windows controls 
with themes support.

Free Life
Boaz

Re: registry TODO

[Boaz Harrosh]

James Hawkins wrote:
Nobody's working on it, so it won't be supported until someone cares
enough to do it. I encouraged a few people to start working on it but
nobody did, so taking out the existing support is a way to provide
more encouragement. If that's not enough then the feature simply won't
be supported anymore.
   

I started toying around the current and old code, Gathering knowledge 
and ideas. What I think of doing is:
 keep the boot registry as is (more less). Put in on wine/wine/config a 
key system that enables a "plugin" system of registry loaders/savers. 
Builtin plugins are current format and Windows binary format. Other 
formats could be easily implemented; candidates could be XML, MySQL etc...
The system I thought of would also save the hives and sub trees, to the 
files/plugins it was loaded from. Each plugin could also implement a 
write behind so Data don't get lost in case of a crash or power lost.

Good point with the on demand-loading/cache of keys. It should be done 
this way. So in summary:
1. Implement a Memory registry with plugin drivers and mount semantics. 
This driver goes here, that driver mounts there.
2. Implement 2 basic drivers: Wine builtin format, Windows binary format.
3. Enable dynamic load of external drivers.

The Initial registry system is always loaded from system.reg builtin 
format which is also the "fstab" file of the registry. At minimum every 
thing is exactly like now one (two) files builtin format, and that's it. 
At the maximum it can be highly object oriented with per user, per 
application, per group management.

Please tell me what you think.
Any libraries I should look into?
How is ReactOS's current (future) system?
Free Life
Boaz

Re: Attempt to make buttons themed

[Boaz Harrosh]

Frank Richter wrote:
Hi,
to see how easy (or not) it would be to make the controls use themes, 
I tried to get themed buttons; the result is the attached patch (to 
try it out, you need an .msstyles file and appropriate registry 
setup). It's probably not perfect as it is, comments/questions are 
welcome.

Index: dlls/user/Makefile.in
===
RCS file: /home/wine/wine/dlls/user/Makefile.in,v
retrieving revision 1.88
diff -u -r1.88 Makefile.in
--- dlls/user/Makefile.in	10 Mar 2005 15:47:53 -	1.88
+++ dlls/user/Makefile.in	21 Mar 2005 18:46:31 -
+case WM_THEMECHANGED:
+	theme = get_button_theme( hWnd );
+	if ( theme != NULL )
+	CloseThemeData ( theme );
+	theme = OpenThemeData( hWnd, themeClass );
+	set_button_theme( hWnd, theme );
+	break;	
+	
 

Where you using a native theme DLL or the builtin one? If native which 
one where you using? How did you Isolate it, I mean how many dll's, 
files, and registry is it.

Free Life
Boaz

Re: wine/ misc/registry.c documentation/samples/config

[Boaz Harrosh]

Mike Hearn wrote:
Hmm, I don't see why. You realise we can't write to the native registry
yes? So using a native registry with the old code was equivalent to
doing an import each time you started Wine. For the case where you
install under Windows then run under Wine, you only need one import
anyway. For cases where you change settings under Windows and expect
them to be reflected in Wine but not vice-versa, then yes you'd have to
use winecfg to reimport each time (but this is functionally equivalent
and could be easily shell scripted).
 

The read only was a shortcoming, I did have a script in place that takes 
user changed keys from wine registry and integrates them back to main 
registry, on exit. I can't remember if it was you or someone else on the 
list who suggested this and I followed. What you propose is an order of 
a magnitude more CPU intensive, and when it hurts the most, on load 
time. Before I had a script run in the background after the user has 
left. The work was on a small Wine registry. Now you suggest work on a 
big Windows registry on load time of an application.

We could probably use an environment variable, or auto-detect it in
future.
 

Why not just map it directly into wine/wine/config: All the old config 
keys can be supported. Primary file is loaded in two stages. The default 
wine's system.reg is opened than if a LoadWindowsRegistryFiles is 
specified that registry is loaded in place, that is, merged into the 
existing registry. Other secondary files load in the same logic as 
before as stated by the wine/wine/config keys.
Winecfg at bootstrap (Installation) has a Windows-Less system.reg and 
boots fine. If we want to put up a GUI to configure these settings than 
a notice Just pops up that states that changes will take effect only 
after restart of Wineserver. But the GUI is not necessary. Just open 
system.reg text file and edit a couple of keys, just like config file 
before.

If no one is working on this I could. Just let's agree on the final result.
I never understood the difficulty. We used to have a config file, than 
we opened up and loaded a registry file. And than we would map config 
file values into the live registry. Now we load up a Primary registry 
then optionally Map a second registry file into it.  It is even simpler 
than before.

thanks -mike

 

Thanks
Free Life
Boaz

Re: wine/ misc/registry.c documentation/samples/config

[Boaz Harrosh]

Mike McCormack wrote:
You're very quick to accuse.
This is a techical list and we are technical people, so let's have a 
technical discussion about the benefits to Wine of the change, rather 
than a mud-slinging, name calling flame fest, OK?

I take every thing I said back. I meant in a technical focus sense. It 
was not clear, and You are right in being offended. Please every body 
who felt on the other side, forgive me!

Thirdly, the description of Wine, from the front page of 
www.winehq.org is "Wine does not require Microsoft Windows, as it is a 
completely free alternative implementation of the Windows API 
consisting of 100% non-Microsoft code, however Wine can optionally use 
native Windows DLLs if they are available."  There's nothing about 
Win4Lin like functionality in there.
Until recently it was also "and Optionally use native registry".
Mike

Re: wine/ misc/registry.c documentation/samples/config

[Boaz Harrosh]

Mike Hearn wrote:
Oh for goodness sake, Alexandre already explained that the whole purpose
of this change was to start on moving the config file into the registry
so we can use winecfg. You know, winecfg, that program that CodeWeavers
don't need because we already have our own? That program which I myself
have helped write?
 

Ok I apologize I was a bit harsh. Maybe it is true in the negative 
sense. If it breaks Crossover it can wait.

You can use a real Windows drive with Crossover, we don't disable it. We
just don't provide tech support for that configuration (for good
reasons!). Using a fake windows drive is the default, just like WineHQ.
I'd note that Jeremy White has actually suggested us supporting people
re-using real Windows drives before because it's sometimes requested by
customers but that idea was nixed due to extra support costs. So it's
not like there is some borg-like collective mind at work here saying
"using native Windows stuff is evil". That's a total fantasy.
 

Exactly my point, a business plan view of the code. Off course Crossover 
can do it ("could" in present tense), it is wine. Actually the Hebrew 
App I was talking about, I started my work on Crossover. I did an 
Initial crossover Install, switched to alternative, native directory, 
than Used Crossover to install some stuff. Than switched to Winehq 
Hacked dlls.
If I did not state it clear enough, than please forgive me. I do not say 
any thing is Intentional and/or pre-meditated. I'm just saying it is 
focused, and so it should.

Given the huge amount of code that's gone into installers lately I'd
like to think this "use case" will shortly become unnecessary. But yes,
there will always be at least one installer we cannot run. 

I think we'd do just as well to provide a little tool you can run on
Windows to watch a software installation and import the registry
entries/files into Wine. 

 

This is where you are wrong my friend. You will never get there. Windows 
is a moving target and Wine is always doomed to follow up. There is a 
constant: "not yet implemented". Thumbs up for the job already done. It 
is incredible.

The tool you propose is not it, as I said in my first post, "Dynamic" is 
the only solution for what I was talking about, i.e. the use of same 
registry.

OK, so I'd rather this functionality did not have to be dropped, but I
know *for a fact* that we are asked about winecfg a lot more than using
Wine with a real Windows setup. Alexandre hasn't ruled out putting it
back in, so if somebody wants to they can take the code and re-integrate
it in a way that makes AJ happy (in winecfg or whatever).
 

That is because it is the type of people you will not here about.
You must admit that AJ is the most allegeable in making AJ happy. So if 
he removed it, what are the chances I'll make him happy?
If Winecfg breaks such basic functionality, than it is badly designed, 
and should be rethought. I don't want to go into a technical argument 
here. A registry bootstrapping registry is probably a difficult task. 
You need a seed registry that can later in the boot, merge with a bigger 
registry. Hence the use of config file before. On windows I do not have 
control on the registry files used, and I cannot share them with other 
installations. So I guess why Wine should be different. But Wine is 
different, it was different. What is more important? Native registry 
support or No Config file. I would prefer both …

Free Life
Boaz

Re: wine/ misc/registry.c documentation/samples/config

[Boaz Harrosh]

Steven Edwards wrote:
I have to agree. Short term being able to load the Windows registry and Windows
system dlls helped Wine but long term it has led to stagnation. Most of the
recent growth in Wine in past few years has been because we are being forced to
not be dependant on a existing Windows install or Windows componates such as DCOM
IE, MSI, etc which is a good thing.
 

Well! Above logic just eliminated Wine my friends. If Native dlls and 
Registry is a set back on "Free" Wine development, than logic would 
follow that, running native Windows applications (Wine) is a set 
back/discouragement of Free SW development.

I'm almost sure my words will change nothing, but I must say them! (And 
maybe they will)

Wine development as been following CodeWeavers business plan for a long 
time, which is more than fine, but this time it broke a statuesque.
   Not being able to dynamically load a Windows registry. Almost 
completely eliminates the possibility of a None CodeWeavers (Like) Wine 
use. Let me explain. 2 examples to use wine None Codeweavers way.

1. I have a legal copy of Windows I want to use in Linux (say). Well OK 
a one time, static transition. Winecfg above could cope with that, 
unless I want to double boot. There have been more than me users out 
there that double boot, the same windows installation. There use to be 
lots of options for control of mix and match. Programs that would not 
install, but would still be usable, by installing on the Windows side. 
One good example is MSDEV 6, and many others. Hell have you ever tried a 
"fake drive" Samba mounted on a live XP System. It works and after the 
Installation/configuration is resolved it is even very stable.

2. A Win4Lin type Wine installation. - Imagine I take ReactOS kernel and 
mix it in with Wineserver. (OK if I did such a Hack I can probably also 
return the Windows registry loading code) This gives me an almost 
complete Windows compatibility on Linux. Well in small term it is done 
today, many times. I had this Hebrew application that absolutely refused 
to work on wine. But with combination of method one and down right short 
circuit some API's I was able to run it on all Native dlls but the Holy 
Grail. For the sake of this program it was a complete WinXP. Just the 
way Win4Lin applications see a native Win95. My solution was only good 
for the App at hand. But it could be better generalized.

Removing Load of Native windows Registry, Breaks the very Logic that 
Wine stands on. For me it is like saying don't Load PE dlls, use Winlib 
ones. I mean the support is there guys. You cannot remove it. If current 
loading order breaks other things you need to do, than fix it. But 
removing it is not a viable solution. It narrows down the use of Wine to 
the point of no choice, No alternatives, and no Half baked solutions. 
Ether it works or it doesn't.

"The above function has no use in CrossOver, so remove it, if it breaks 
my head"

People! who am I to talk. My Wine Installation is 7 month old. And my 
wine Hacking is back to nights and weekends. But Philosophically my 
message is sound. Don't agree with the messenger Just listen to his message.

Free Life
Boaz

Re: unixfs

[Boaz Harrosh]

Alexandre Julliard wrote:
I think the extension itself is perfectly reasonable. The thing I'm
not sure about is creating a brand new dll for it, adding
Wine-specific dlls should be avoided if possible.
 

I agree about dlls that cause un-standard linkage from using code to 
private dll. But this is a Control. the only linkage is through the 
registry, and is totally optional to any running/using code. It's like 
the Mozilla control or any other utility add in. Just from Winehq this time.

Free Life
Boaz

Re: Drive detection stuff

[Boaz Harrosh]

Andreas Mohr wrote:
Are you sure the apps get notified, too?
ISTR XP doesn't automatically update the Explorer view after you have
plugged in a USB stick, or maybe I'm wrong?
 

Yes it does. and any program can. There is an API to watch for File 
System changes. From files (for editors), to folders and drives. The 
standard Shell control (Used in file dialogs and Explorer) uses this API 
by default. Also apps that do their own Dialogs like office.

Use of STLPort with winegcc

[Boaz Harrosh]

Winegcc will prepend any of the command line switches with "-I 
wine/include/msvcrt" if the "-no-cygwin" flag is specified. This breaks 
STLPort because STLPort must be first on the search path, before the 
regular c-runtime of the compiler. This way it can do it's tricks of 
what to use and what not to use from the standard c-runtime.

What is the current way to solve it. I could remove the "-no-cygwin"  
flag and Manually add the "-I wine/include/msvcrt" and "-D__MSVCRT__". 
But how do I add the "-dmsvcrt" on the Winebuild command line, as it is 
all internal to winegcc.

What would be the right way to do it? I would submit a patch, but what 
should I do? Just append the "-I .../msvcrt" instead of prepend, or 
maybe use "-isystem .../msvcrt". The docs for gcc say that "-isystem"  
folders will be searched before the default gcc folders but after any -I 
folders.

Free Life
Boaz

Re: Visual C++ 6.0 as a Winelib IDE?

[Boaz Harrosh]

Ira Krakow wrote:
You can set a break point, the debugger runs, and
stops at the break point.  You can inspect and change
variables.
 

This is amazing news. You should submit a little section about it for 
the Winelib hackers guide. And also for the user guides as it is an 
alternative to winedbg. One some people will like better. Eric, Mike 21 
thumbs up :-}

I get it from the lack of an answer that MSDEV installs the regular way, 
and that it is able to compile a project with output redirected into the 
IDE so you can double click on errors and stuff?

However, Step Into, Step Over, doesn't work.  If you
try this after reaching the breakpoint, the debugging
options are greyed out and the debugger ceases to
function.
So I guess it's some progress, but it's not totally
there yet.
 

Eric, Mike can you check this out? Does pe-gdb have the same problem 
with next/nexti?

I installed dev-c++ and really like it!  The DSP
import looks very promising - this is definitely an
avenue I will pursue.  I also like the Visual
Studio-like look, and the fact that it creates
makefiles for DLLs (static and dynamic), console apps,
and Windows GUI apps.  

Haven't tried gdb for Windows under Wine.  Also looks
like a good idea.
 

Use it under dev-c++. Just make an hello word application put a break 
point and press debug. Please do this for me I must know ...

2. Grab the DSW2MAKE util from MinGW. Written in
Perl.
   

These are all great suggestions.  My next chapter will
be to convert a "real world" app, which leans heavily
on good debugging techniques.  I want to define a good
converstion path.  You have helped me a lot.  Thanks.
Ira
 

Re: Visual C++ 6.0 as a Winelib IDE?

[Boaz Harrosh]

Ira Krakow wrote:
I have Visual C++ 6.0 running under Crossover Office
4.1, which of course means it's running under Wine. 
 

1.5 years ago I had 3 problems with this.
1. It did not install. But that was not so bad because also on windows, 
VC6, if you copy an Installed directory and run it. Will work with some 
minor functionality missing. So it did load on wine.
2. When compiling, the std output was not redirected back to the IDE.
3. When debugging, it would Just do a Baaa and quit.

Has any of these problems changed? Can you set a break point and run 
under the debugger?

For one of the examples in the Wine/Winelib book, I
decided to take the code produced by the VC++ Win32
"Hello World" wizard and see how to port it to Wine.
Turns out, it's almost trivial.  Create an empty
directory, copy the *.c, *.rc, *.h, and *.ico files to
it.  VC++ produces tons of other files, but they're
either used to maintain the Visual Studio environment,
or are intermediate compilation files that aren't
needed.  Then run:
$ winemaker .
The Makefile that Winemaker generates _almost_ works. 
You need to delete the references to the mfc library
and mfc.dll.  After doing that, running make generates
the .so file.  Wine runs it flawlessly.

 

There are 2 easier ways that I know of to do this.
1. Use dev-c++ from www.bloodshed.net/devcpp.html. It will Just open 
your DSP file and make a very good, very simple MinGW makefile for you. 
It will add all your -D and -I and all this nightmare in big projects. 
Both the result makefile and dev-c++ itself can be used with wine. It 
has a native Linux port has well.
One thing to try is debugging. It uses gdb for windows. Does gdb for 
windows runs under wine??

2. Grab the DSW2MAKE util from MinGW. Written in Perl. The output 
makefile is very good for Winelib. Also keeps your -D(s), -I(s), and 
-l(s) and tries to convert other switchs as well. Better for very big 
projects.

I got to thinking - can I convert the code from the
MFC application as easily?  Seems like it's doable,
because the generated code runs in VC++/Crossover
Office 4.1.  I tried the same steps as before, with
Winemaker, but I couldn't figure out what Makefile
modifications were needed.
 

MFC/ATL itself is not so simple...
All of this got me to thinking - could Wine running
Visual C++ be a viable IDE for porting?  Maybe just
linking VC++ with the Winelib libraries would do it. 
Maybe after tweaking Winemaker and publishing a HOWTO
we could show that this is a viable path?  It's
certainly easier than for Visual Studio developers and
could help attract them to Wine.
 

If and when the VC++ Debugger can run under wine. (Even remotely) that 
will be the turning point for all the windows developers out there.

Another benefit - we could use the Visual C++ sample
programs as tests for Wine.  The programs might
exercise areas that haven't been tested thoroughly.
 

Go grab CodeGuru.com & CodeProjet.com . There is your exercise of Win32API.
But from what I talked to Jeremy once, he said that from their 
experience, having the PE source code doesn't really change anything in 
the way you debug the app. All you need is the relay-trace anyway. So 
why not Just grab a real live App and have that run.

What do you think?
Ira
 

Free Life
Boaz

Re: Problem using winelib to compile Std Lib strings

[Boaz Harrosh]

Rob D wrote:
The files I cant seem to compile are ones that use std string.

If you are using msvcrt, You cannot use native g++ std with Winelib. In 
this case you'll need to grab STLPort. And hack on it to compile over 
wine & msvcrt headers. This is for two reason. 1- The headers are 
incompatible (Headers separation is really bad especially gcc's) 2. 
you'll have a risk of runtime memory corruption, as programmers usually 
mix between allocation methods. So you'll have some buffers allocated in 
Wine system that try to released on g++ heap and vis versa.

If you want I can package for you an OLD STLPort. The dynamic Libraries 
you will not be able to use as it uses a very old wine build. But you 
should be able to compile and use the static libraries.

The development Ive been tasked with will move several people off of
winblows machines and onto Solaris 10 if I can succeed, so it is even
more critical in my mind to get this to work.
Yes this is very important! If they're used to Windows MSDEV. they might 
like KDevelop3, and the debugger is also nice for Winelib. You do have 
KDE libs for Sun right???

Free life
Boaz

Re: [ros-dev] RE: Collection of wine tools on windows

[Boaz Harrosh]

Rolf Kalbermatter wrote:
This is rubish. 

Yes ^ 3 ( that is Yes cubed)
Let us all get back on track of this discussion. Must ReactOS and MinGW 
use the Wine set of headers.

1. ReactOS & MinGW are by themselves GPL, So they are more strict than 
Wine's header set
2. Headers are out of the scope for License as Rolf explained.
   Or to be more precise they are the boundary put by the License. 
"From this API down you are in Library territory".
   The header is the Line drawn by the Library writer, as what is 
public API. A GPL program is an LGPL library with the trivial public 
header of:
int main(int argc ,char* argc[]) ; // use only 
3. Wine Headers are description of the Win32 API by Microsoft, so what 
the hell are you talking about.

And back to the subject. I have proved that Wine-headers are not only, 
nice-to-have, but a must in a gcc compilation environment on Windows, 
like MinGW or Cygwin. Could/did any one see if ReactOS has every thing 
they need in wine-headers and if not patch in the diff.

So is it accepted than!
Free Life
Boaz

Re: Winemaker questions

[Boaz Harrosh]

Francois Gouget wrote:
__TRY {}/__FINALLY()? I'm not sure the changes I did are now compilable
under MSVC nor MingW.
4) Would there be a way to transform __try {}/__finally{} blocks to
Unfortunately they don't work exactly the same. There has been many 
attempts to improve exception support in Winelib but none that were 
deemed good enough to be committed to CVS.
Below is a technique I use in C++. I'm not sure it can be used in C. But 
if you have C++ it is perfect. And nothing needs done in Winemaker Just 
have the #define available before the using code like in your StdAfx.h 
file.

<__try__finally>
#define __try try
#define _CONCAT_(s1,s2) s1##s2
#define __except( foofoo ) \
catch(...){ \
int d = foofoo ; \
switch(d){ \
case 0: \
  throw ; \
case -1: \
case 1 : \
goto _CONCAT_(gifs,__LINE__) ; } } _CONCAT_(gifs,__LINE__) :

the CONCAT macro is because of the pseudo 2 pass of the preprocessor, 
Other wise the __LINE__ is not expanded to produce a unique goto label.
goto is used to jump over the "}}" closing scope of the catch and 
switch. So using code does not change. (There is one restriction you 
can't use 2 __except statements in the same line)

Free Life
Boaz

Collection of wine tools on windows

[Boaz Harrosh]

There is a question at the end.
Background:
 I'm putting up a Web-corner with ATL & MFC for other (gcc for now) 
Compilers. It will include tools, links, documentation, example 
makefiles, and so on to let people take an MSVC project and compile it 
under GCC. (+Winelib on other than windows platforms)
 My first release target is Windows/ReactOS MinGW-PE. What I did is 
take the work I've done on Linux and port it back to MinGW. At first, as 
I expected, it did not work at all. So what I did without hesitation is 
fetch the Wine headers set, + (yes) wine-msvcrt. Completely removed 
MinGW originally supplied headers put Wine on the Include path, and 
voila It was compiling Just like on Linux. (Well it didn't link, than it 
didn't run, because of the weak symbols thing but I fixed all that). I 
find 3 things bad about MinGW headers. (Please don't take this as flame. 
I have all the admiration for all  involved and no offense is intended)
1) MinGW header-set are Evil - Because they are ugly, with this, no 
variables names, and all this style for machines guide. This I already 
carry for 10 years so here it is off my chest.
2) Win32 is not complete - I would say that MFC and ATL/WTL are a very 
good exercise for the completeness of the Win32 API. Well the wine stuff 
have every thing we need, MinGW does not
3) msvcrt - msvcrt compatibility is far from satisfactory on MinGW. 
Wine, since they had to re-implement msvcrt.dll had to have all these 
funny MS permutations of the c run time. Compiling on MinGW is almost 
like using wine without MBCS defined. MinGW headers are mainly derived 
from GCC c-runtime, with a few adjustments for the -mno-cygwin mode. But 
they are greatly missing all the esoteric stuff that is needed by MFC 
and ATL. Wine is perfect, thanks to CodeWeavers, need to run all these 
MFC apps out there.
4) (I know I said 3) It is time, that all projects collaborate on ONE 
set of headers and ReactOS is the bridge to that - It is a long time do, 
that Wine's Set of headers are adopted by all projects. MinGW 
concentrates on PE gcc compilers, and pass the Win32 project to wine. 
Wine will release a headers only package for every body to use. (This is 
what I'll do on first release of my project)

[Question to the ReactOS team]
 The windres utility is insufficient for Most of the projects out 
there. For example one reason my project is not already on the air. (And 
hence my post) is that it refuses to compile my Toolbar resource tag. 
(And what is an MFC app with out a toolbar).
 I have seen some work done on porting wrc to PE is that work done and 
will you have a pre-compiled binary package for use to use on 
windows/ReactOS. Same applies to widl. ReactOS should adopt all these 
Wine tools as part of their regular tools portfolio. MinGW should adopt 
Wine's / ReactOS's leadership on all these technologies and supply-link 
to them by default. Go duplicate all these goodies the wine guys are 
preparing for us with widl.

Again guys please let the passed be gone. And put our differences behind 
us. There are grate things happening, clearly Wine is the Leader here, 
lets do this sooner than later. Dimi I need your help here

Free Life
Boaz

Re: Microsoft genuine downloads looking for wine

[Boaz Harrosh]

Ge van Geldorp wrote:
When using IE and thus the ActiveX control there is no problem and my
Windows is recognized as genuine.
Looks to me the standalone validation program is seriously broken
 

What about IE under Wine. It looks like that might work?

Re: Winelib and SCons

[Boaz Harrosh]

Scott Ritchie wrote:
Then, the developer needs to write his own makefiles and hammer autoconf
and stuff into working right.  This is the hard part, and it's where I
gave up when trying to port Miranda Instant Messenger with Winelib even
though it worked in MinGW.  There are many other open source Windows
apps out there that I'd like to try porting (say, eMule), but they're
currently all written in Visual Studio and getting Visual Studio support
into Winelib has been on our perpetual todo list for some years now.
I use dev-c++ from http://www.bloodshed.net/devcpp.html It has a very 
good dsw importer and makes a most simple MinGW makefile that can be 
used outside of dev-c++. Also on wine.
But who wants to go outside, It is loaded with goodies. Code completion 
debugging class browser the works. It has only 2 flaws. That it doesn't 
use the Scintilla editor, and that it doesn't drink it's own soup, see, 
even though it is GPLed it is written in Delphi.

Free Life
Boaz

Re: Compiling the MFC using Winelib

[Boaz Harrosh]

Geoff Hart wrote:
In fact, I often wonder why his work (which is very impressive) was 
not included in the base?  It would
seem ATL/MFC support is a very worthy addition to Wine.  Anyone care 
to re-discuss why his patches
were rejected?

This is my own fault I never sent them.
I sent them to wine-devel and not to wine-patches for review. I did not 
send them because they are kind of useless with out an example Project 
and Makefiles, and the ones I have are all old vanilla gcc Makefiles. I 
never came to the point to port them to winegcc Makefiles. So they are 
Just there on the mailing-list archives.

Free Life
Boaz

Re: MAPI32.dll.so - how to use in linux programs?

[Boaz Harrosh]

Luke Kenneth Casson Leighton wrote:
... i am kinda looking for something with a Makefile, compiles and
links against Wine directly - under linux not windows.
i am inclined to rip bits of code out of Wine (parts of header
files so far) until i can get to grips with it.
 

It looks like what you are looking for is a vanilla Winelib application. 
It compiles on Linux with a Makefile it can freely be linked to any 
Linux resource/Library and in turn also use Wine or native windows DLLs. 
Only thing is that it is executed under the Wine loader and must keep 
some linking and structure rules special for wine. Once it works it is 
easy to take code from a Winelib App and make it a Winelib  DLL.

So Just look at the Winelib programmer's guide (On Winehq) documentation 
on how to make a Winelib application.

Hope that helps
Free Life
Boaz

Re: RICHEDIT once again

[Boaz Harrosh]

Krzysztof Foltman wrote:
My rich text control is still far from even semi-complete, but I think 
too much is done to start over, so I'm releasing it today. The number 
one reason of its incompleteness is that I put more emphasis on making 
things work exactly like in the original than on implementing more 
functions.
Sorry to be barging in like this and maybe it is all Old news. But ...
I have been using in a few projects, Windows side and Linux, a grate 
rich edit control, I'm sure every body knows, and used even if he 
doesn't know. "Scintilla"! It has anything a RichEdit control needs (and 
much more but that does not have to be used). It even has the export to 
RTF function. (And to HTML for clipboard operations) It has 95% EditBox 
emulation. It is very stable, heavily used and debugged, and highly 
portable. The License is a BSD type license so I don't think it will be 
any problem. The only things missing are the RTF parser and the 
MS-RichEdit emulation (Data types and message translations). But it 
looks like these two are what above patch and existing code has. I am 
almost positive that if such a parser (And emulation layer) is submitted 
to the Scintilla project it will be farther maintained by the project. 
One more thing good about it, that makes a lot of sense, is its 
popularity, which means there are a lot of people that know this 
code-base and can help fix problems. (And it does compile under wine out 
of the box.)

Please forgive me if all this is "Old News". I didn't check the 
archives. Any way just my $0.02.

Free Life
Boaz

Re: Compiling the MFC using Winelib

[Boaz Harrosh]

Brian Vincent wrote:
On Sat, 22 Jan 2005 13:19:35 -0800, Dan Dennison <[EMAIL PROTECTED]> wrote:
 

Are there resources available beyond simple compilation tips to assist in
the building of the MFC library under Winelib?
   

Excellent.  Also, does anyone know the (US) legal aspects of this?  Is
there a EULA that prevents it or doesn't prevent it?  Is
redistributrion allowed in any way?  Bonus points for figuring out
what countries it's legal or not legal to do so in.
-Brian
 

I checked it out. Actually I had some e-conversation with the MSVC 
project manager.
To put it as simple as possible: You can publish any using code as you 
wish. You can look at sites like Codeproject and Codeguru. They have 
lots of MFC/ATL related code freely on the net.
You cannot however publish any MFC or ATL code or fixed code. We had a 
discussion about DIFF files and he was not sure about them, has he is 
not a legal professional. So he said I'll have to get in touch with the 
Legal department at MS - Which I did not. A lawyer friend told me that 
DIFF files are problematic since in the "-" statements and surrounding 
code is actual MFC code that is IP of MS. A binary patcher would be 
better for that. However it is definitely aloud in the EULA that I send 
you a DIFF file if you are a legal owner of MFC (MSVC++) and I am 
employed by you (Part of your team). But my lawyer friend said that if 
put to court. Then It is better I had proof that you paid me for that 
work. (Even something trivial).
So in short Derived work (ala Codeguru) is allowed and recommended. 
Actual MFC even changed MFC is not. It is, if it is for me and I'm a 
legal owner of an MSVC++, for any purpose on any platform.

Needless to say, that they where not Interested in the patches I had for 
ATL that makes it compatible for other compilers. And is perfectly good 
also for MSVC++ compilers. My reasoning was that this way ATL can be 
used for COM/DCOM servers that run on other platforms (Mainframes to 
embedded systems). His answer was: that they have support for all these 
platforms as WINCE and Win/U and special MS partners. (Which is not 
true) Win/U has a special version of MFC but they do not, or can, 
compile ATL/WTL, for all of the same reasons, MSVCsim .

Free Life
Boaz

Re: Compiling the MFC using Winelib

[Boaz Harrosh]

Dan Dennison wrote:
Are there resources available beyond simple compilation tips to assist in
the building of the MFC library under Winelib?
Thanks!
Dan Dennison
[EMAIL PROTECTED]
 

I have done it up here last year. I did not post any results because by 
the time I finished they changed the winelib make system on me (move to 
winegcc) and I could not find any time to update it. If you want that I 
send you all the old system I can do that (Save the MFC source itself of 
course). Here are some notes on my experience.

MFC was actually easy. At the end I had MFC compiled out of the box with 
a trivial number of changes. The real changes are very few.
1. The "(...)" functions and C++. In msvc if a C++ object is passed to a 
printf like function the object is Just put on the stack struct style 
(all members pushed, so that, at the end, the exact struct layout is in 
stack memory.) In gcc it will issue a WARRNING and core dump in runtime. 
So in MFC all print("%s" ,aCStringObj) need change to printf("%s" 
,(LPCSTR)aCStringObj) .
2. A very few "typename"s missing in templates. (MSVC7 MFC is better in 
that but has other problems)

That's it, no real code change, and NO comment out of 4000 lines (Like 
mentioned in wine documentation.)

The all secret is in the compiling Environment and the set of headers files:
3. Other than the pure MFC source files you will need other MS headers 
from MSVC\Include and MSVC\crt\src Since they come with the same License 
as MFC you can use them freely. (If you paid for your MSVC copy). Here 
too I can send you the list of extra needed files. My List is old and 
probably some are already not needed as wine catches up very fast. I did 
not put these headers in the wine/Include but in an extra Include dir 
that has lower precedence than wine/Include, so any headers missing from 
wine are taken from msvc/include. (At first I took the all MSVC headers 
set and winemaker them). Later I narrowed them down to as needed bases.
4. Some g++ headers need a special copy inside the wine tree and the 
-system (I think that is the switch) use, so g++ does not try to find 
any of its original headers. These are the "typeof" and other core C++ 
headers. And they need to be changed a bit mainly to be able to survive 
with msvcrt wine headers, and to not reference any gcc originals. (This 
step is mainly for STLPort and ATL see below). In general NONE of the 
original GCC++ headers can be used. This is because:
5. Use the MBCS switch in wine. MFC is highly MBCS and I think even in 
msvc on windows it will not compile with out it. (Perhaps UNICODE is 
also good but I never got there) And with out mention you need to use 
msvcrt (-nocygwin).
6. All these "Get off my neck and stop sucking my blood" GCC switches 
must be used. Most of them are mentioned in wine documentation and/or 
are default for winegcc, maybe a couple extra for C++ specific stuff.
7. Compile main ATL. The main ATL files (3 I think) are included in 
MSVC6-SP5 version of MFC. If they compile your life is much easier. Here 
as opposed to MFC there are more changes to do. (But it is only a few 
files). See my post of one year ago on the wine-devel archives search 
for "For compile of MFC and ATL". Attached are a couple of patches that 
will make your life a bit easier when compiling ATL. Or maybe find an 
MFC that does not use ATL (old versions did not)
8. To Makefile or not to Makefile, this is the Question? By far most of 
the work is in the Makefile (and directory layout). You must decide if 
you want a static lib or a dynamic fake C++ DLL. In some projects you 
must have the later but it is harder to do, (and very slow on load 
time). Than you need all your winebuild/winegcc flags just right. 
(Depending on the type of lib you're building)
9. WARRNINGS. Try to eliminate any warnings because in G++ some warnings 
are errors. (See above) See my Patches (above) on how to do that.

This is just what I remember probably it is only half of it. If we look 
at 8, above, it is perhaps easier to do what Dimi always says. First 
compile it on MinGW on windows than you can be sure your Makefiles are 
good, than the winelib is 90% there. (I never did that so I'm not sure 
what problems hide there). But for sure you will not have 2, and you 
then know the file listing for 3. If you do go that rout than MinGW 
project will also be happy with your paper as well as Wine.

Well good luck
Free Life
Boaz

Re: Wine scheduling and threading issues [was Re: Threading issues...]

[Boaz Harrosh]

Ingo Molnar wrote:
It would be nice if someone with a proper Wine test-setup could check
whether _negative_ renicing of highprio Windows threads solves the
scheduling problems. In fact you could even try to map Windows
priorities (16 levels available to nonprivileged users?) to the nice
range of -7...+7, and run the test as root so that the renicing
succeeds.
	Ingo
 

I did something like that. I ran wineserver as root and a user wine app 
with same WINEPREFIX. The priorities work as expected and it was working 
for the mediocre app I had at the time. As Jeremy said, it is never the 
right way to do it programmatically.

I was working on a system where wine is installed by an "administrator" 
Linux user with some privileges and all users shared the same 
wineprefix. (Multi-user wine, a bit like the NT model.) I abandoned it 
because of the problem I had with multiple displays. And also my Linux 
IT knowledge is not up to it so I had problems with file access and stuff

Re: [winegcc] Include .so files when calling winebuild

[Boaz Harrosh]

Alexandre Julliard wrote:
I'm not sure I follow you, if your .so files have been built correctly
they shouldn't contain undefined references to Windows APIs. Could you
please show an example of the situation that causes a problem?
 

.so that are not compiled as dll or fake dll (fake dll is when the lib 
looks like a winelib dll to the wineloader, but is actually also linked 
gcc style for C++ symbols) will have problems with startup and global 
symbols and code. especially if this code calls any wine code, for 
example msvcrt.

Free life
Boaz

Re: Support for running Winelib apps directly

[Boaz Harrosh]

Vincent Béron wrote:
Remove the loader script from Winelib apps. Winelib apps are still .so
files, but they can be launched directly now.
 

We did try to keep up with what wineapploader and wine did to load a 
fake-dll winelib app and all the spec.c magic that linked it all.
Could you please elaborate a bit on what has changed and how it is all 
glued together? Is the embedded wineapploader Process reused for the 
main process for easier debugging? Currently when you debug a winelib 
app under GDB you cannot use wineapploader you need to use 
wine-kthread/pthread directly, and disable execshild and friends all 
together. Will that be at all possible now?

Do you think it can be easier now for a: let's call it Unix app, to 
become a winelib application mid-flight. Lets say, when it wants to load 
a PE plug in DLL. (The way of mono and that Audio program can't recall 
the name). Could a UnixODBC (elf dynamic lib) force a load on a PE ODBC 
driver, therefor making the running app a winelib, Like PHP for example? 
If so could you make a little hello-world example of how it is done?

Grate work
Free Life
Boaz

Re: Support for running Winelib apps directly

[Boaz Harrosh]

Vincent Béron wrote:
Remove the loader script from Winelib apps. Winelib apps are still .so
files, but they can be launched directly now.
 

We did try to keep up with what wineapploader and wine did to load a 
fake-dll winelib app and all the spec.c magic that linked it all.
Could you please elaborate a bit on what has changed and how it is all 
glued together? Is the embedded wineapploader Process reused for the 
main process for easier debugging? Currently when you debug a winelib 
app under GDB you cannot use wineapploader you need to use 
wine-kthread/pthread directly, and disable execshild and friends all 
together. Will that be at all possible now?

Do you think it can be easier now for a: let's call it Unix app, to 
become a winelib application mid-flight. Lets say, when it wants to load 
a PE plug in DLL. (The way of mono and that Audio program can't recall 
the name). Could a UnixODBC (elf dynamic lib) force a load on a PE ODBC 
driver, therefor making the running app a winelib, Like PHP for example? 
If so could you make a little hello-world example of how it is done?

Grate work
Free Life
Boaz

Re: source level debugging with WineLib?

[Boaz Harrosh]

Geoff K. Hart wrote:
Hello,
We just started using WineLib, and have very basic question:
 which -g??? option do you use to do source level debugging
 with winedbg?
 

There is no point in struggling with winedbg, with a winelib. wine and 
winelib apps can be fully debugged with gdb. I use a full screen gui 
over gdb, kdevelop, give it a try.  What you do is :
- find out if on your system you are running wine-kthread or 
wine-pthread. (wine is Just a loader that figures out which one to 
load). Than at the gdb settings the executable for debugging is that one 
(wine-pthread or wine-kthread)
- have all the right command line parameters to invoke your winelib app. 
If you have environment variables need set do that before you run the 
debugger or at the debugger before the app is loaded. In kdevelop there 
is a nice settings dialog to set all these things once.
Actually one of the points of a winelib is that you can use the native 
debugger.

Free life
Boaz

Re: How difficult would it be to make the equivalent of Windows Terminal Server with Wine?

[Boaz Harrosh]

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 interesting if Mac/Linux/Unix users could use their browser
of choice and their native X server, which is usually already installed on
those platforms. How exactly is this approach dependent on the use of an OCX?
-Hans
 

Very good question!
Once I de-wrinkle all details with my boss, I want to publish the source 
for the OCX. The first "todo" it will have is the:
How to port to other platforms/browsers.?

On the Server html page I have the  tag with the 
CODEBASE="path2cab/xwidget.CAB" attribute
(xwidget is what I called the OCX)

I have read that there is a way to have platform/browser specific 
installation packages. But than how to do it with each platform?
I don't know? any Mozilla guru out there that can help. On Linux all you 
need is a client side access to the shell. And also on Mac OSX.

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)

It is all very Client un-safe and should probably be confined to the 
IntraNet only. Server safety can be kept.
Maybe the best would be to embed the ssh inside the Object and not let 
the server have a shell access on the client. I'll see how it goes and 
if client safety is requested at all.

Free Life
Boaz

Re: How difficult would it be to make the equivalent of Windows Terminal Server with Wine?

[Boaz Harrosh]

Andrew Quigley wrote:
What I would like to be able to deploy would be a system which runs 
multiple Win32 compatible desktops and multiple logins on a server, 
with the clients accessing the desktops via RDP or ICA protocols.  How 
many of the pieces required to accomplish that already exist, and what 
pieces have yet to be built? A quick search on freshmeat shows me a 
few different rdp clients, so it looks like the protocol spec is 
known. What would be involved in creating a RDP server that shows up 
as a video driver as far as the win32 programs are concerned?


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. You put a page with the 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 do intend to publish the OCX project as GPL. And the wise-script to 
package the Cygwin/X installation. And also have available the binary 
package.

Hope that can help
Free Life
Boaz

Re: add epoll implementation to libwine_port (take 3)

[Boaz Harrosh]

Mike McCormack wrote:
But first I'd like to try and get this more simple improvement 
accepted into the CVS.

Amen

Re: add epoll implementation to libwine_port (take 3)

[Boaz Harrosh]

Mike McCormack wrote:

ChangeLog:
* add epoll implementation to libwine_port

 


+__asm__ __volatile__( "pushl %%ebx; movl %2,%%ebx; int $0x80; popl %%ebx"
 

Grate !
[Q] Does that mean that we directly check if it is supported in kernel, 
bypassing glibc all together? how do we avoid conflicts with glibc?

Re: How to port c++ program to linux using winelib

[Boaz Harrosh]

Eric Frias wrote:
Thanks for the suggestion!  Even if it isn't elegant, it sounds like it will
work (and is very close to what we were doing with the older wine).  I might
even be able to coax our build system into generating all of the *_export()
and using_dlls() functions automatically.
 

Yes I have a macro system that does that so it is something like:
USING(My_dll) or
EXPORT(My_dll)
the .spec is generated by make from EXPORT(xxx) lines
But your suggestion looks better
Was all of the time your application took to load because of wine's DLL
import mechanism, or because of the shared loader in linux?  One of the
reasons we are trying to upgrade to a more recent version of winelib is so
that we can try some of the 'prelinking' tools to try to make our app load
faster, so I'm curious where all of the time is spent.
 

Most definitely the Linux-shared loader. It took ages. The code is heavy 
C++ code full of templates with weak symbols, inline virtual functions, 
and plain horizontal code structure. almost any thing you can do to slow 
a linker down. The PE export-import tables are much better in this 
situation since there is no searching to do. (and no fixups) All 
searching if any is done in link-time. (Run time on the other hand is 
slower). Actually this app is very bad on Windows too. So we compile it: 
"all libraries static" when doing "Release" code. We use DLLs in debug 
because the static linking takes 15 minutes.

Speaking of which I was never able to statically link the winlib app on 
Linux. I put up a machine with 2-Gg of ram + setup 2Gg of swap space. 
The linker would work for 5-10 minutes than it would hit the swap space. 
Memory would go up  and up until about 50 minutes where the kernel 
starts to kill every thing in sight including the Linker. MSVC++ does 
not do that, it uses temporary files. Lots of them, to finish the link. 
I did not even try none-debug builds because the all point of the winlib 
was that Developers could use full screen debugger (Kdevelop) to debug 
Linux problems. If we only have traces and relays than PE is Just good 
enough.

Thanks for letting me whine.  ;-)
Please do post your results on how to Link the .so on the winegcc 
command line. And also most important if you succeed with prelinking. I 
think that is the best way to go but I'm not a Linux guru and didn't 
manage to do it.

Free Life
Boaz

Re: How to port c++ program to linux using winelib

[Boaz Harrosh]

Eric Frias wrote:
Does anyone have a solution they're happy with?
 

<>Not happy and is a bit out of dated but it Looks it could still work 
today.

Do a .spec file for each C++ dll with one c function like:
void mydll_export( )
{
}
// you need real code + .spec declaration
In your app or in the dlls that use the above dll do a function like:
void using_ddls()
{
  mydll_export( ) ;
  mydll2_export() ;
}
// this code forces the winebuild to pull-in listed dlls as well
link every thing the regular wine way this way DLLS load in the right 
order, get initialized, and their Windows "import tables", like calls to 
kernel32 etc, gets initialized by the loader.
But (and here is where I'm out of dated) also specify the .so as a link 
option to the gcc linker. (ld)

In the old system, before winegcc. One would do -lmydll on the winebuild 
command line. And than in turn -lmydll on the ld command line - for 
resolve of C++ symbols. Now that we use winegcc I'm not sure what is the 
switch for additional libs like .so and static libs. Look maybe it is 
documented. (Dimi how do you add external libs to a winelib link stage 
under winegcc?)

But be careful with this approach. It is an order of a magnitude slower 
on load time than DLL linkage on windows. I came to a dead end with one 
of my projects, where I managed to compile and run every thing but I had 
to revert to PE compiled code because it took my app 4-6 minutes to 
load. (PE takes 40 seconds). It was a 1.2 M lines of C++ code divided in 
to 37 DLLs + MFC in a dll.

We have talked about the right solution with Alexander on Wineconf. What 
he suggested was:
1 - make the __declspec( export ) macro expand to a gcc "section" 
declaration. So the compilers put all of them in a special section. No 
one knew how C++ classes behave with "sections" and we suspected each 
member function has to be put into the section by hand. On windows a 
__declspec( export ) on the class declaration automatically exports all 
members. Maybe MinGW could help out here.

2 - Use a tool like nm or readelf to extract all symbols (including 
C++), in above section, and with a script convert them to a .spec file.

3- I think that current winebuild have problems with some variants of 
the C++ mangled symbols like the use of the "@" character. So maybe a 
new "C++" style function should be added to the .spec syntax, that will 
not try to interpret the symbols.

Free life
Boaz

Re: Upgrade management

[Boaz Harrosh]

Mike Hearn wrote:
Wouldn't it be better to do good testing and have, ooh, I don't know, 
a beta testing program? In other words, to ensure we *don't* mangle 
the users data?

Yep that too.
I'm not sure we should design this system on the assumption that we 
suck and will probably blow things up. I don't know of any other 
programs that use such a mechanism when upgrading!

I am not saying that. I'm Just saying. Give me the --noupgrade 
potability. for checking out stuff. Some programs cannot survive side by 
side with multiple versions of them selfs. And the Installer will remove 
the old version. Those who do. take measures to protect users. Even new 
version of WORD will prompts you when you try to save an old version file.
If wine was installed from rpm and is updated - it is one case. The old 
version is gone the new one is replacing it. But if the old version is 
still alive. The new one should not take hold. In my opinion you should 
have the upgrade option in wineprefixcreate by all means. Than it is the 
packager/Installer responsibility to run it when appropriate. But it 
should not be left to wine-run to decide, unless you keep some kind of 
reference count on installations which is hard and complicated.

Any way sorry for this flame . I Just wanted for you to see the commonly 
used scenario of 2 version running side by side and to let us geeks have 
that possibility in the future. The Upgrade option is commendable and 
highly needed, Just not automatically, for me.

thanks Boaz

Re: Upgrade management

[Boaz Harrosh]

Mike Hearn wrote:
There is evidence that users don't see or ignore such warnings :(
If you aren't confident that an upgrade won't break stuff you can 
always manually back up the wineprefix before running the new version, 
I don't think we need to do anything ourselves. Most users won't be 
administering production environments, and for them automatic upgrades 
would be helpful.

I don't know, better safe than sorry. You are touching users Data here. 
they should have an informed choice. A message box, something? maybe 
refuse to run, than he will notice.
So a first time newbie installs wine and is very happy with it. After 
1/2 a year he feels more confident and the new release fixes a game he 
likes or something, He tries it out and his old setup is broken. Than 
what he think off wine? Unless we state it in bold letters in every 
possible documentation (and have a cancel flag like --noupgrade) than 
you must confirm with the user.

thanks -mike

Thanks -Boaz

Re: Upgrade management

[Boaz Harrosh]

Mike Hearn wrote:
There are a bunch of different ways we may want to upgrade the users 
configuration:

- Changes to $WINEPREFIX (~/.wine), for example:
   - Introducing faked DLL headers
   - Improved drive detection
   - Changing the way the registry is stored
   - Adding stuff to the virtual Windows drive
- Modifying the registry
   - Adding new keys
   - Adding new appdefaults (default config options should be in the
 code itself). While we have a policy of not having app-specific
 hacks in Wine, some situations are very hard to resolve without
 custom overrides. The Internet Explorer installer does a bunch of
 things we really don't want it to do. The DCOM
 installer needs custom overrides to convince it to install. And so
 on.
   - Registering new COM DLLs
   (these all boil down to rerunning wine.inf)
- Adding new binaries such as fonts, PE DLLs (think Moz AX control),
  and so on. These may be placed somewhere in the Wine install directory
  and then symlinked or copied (presumably linked) into drive C.
This leads to the following questions:
- How do we know when to upgrade the users wineprefix?
- How do we avoid disturbing the users configuration?
- What implementation do we use to upgrade it?
One potential implementation for knowing when to upgrade the 
wineprefix is to version it in a similar manner to how we version the 
wineserver protocol: with a simple incrementing integer. This could be 
stored in the registry, and Wines initialization sequence changed to be:

 ...
 Does $WINEPREFIX exist? No, call wineprefixcreate
  -  Continue with startup
  +  Yes? Check the wineprefix version key, if it is < the
  +  version compiled into the source run
  +  "wineprefixcreate --upgrade $oldversion $newversion", which then
  +  performs the upgrade. If it exits with a zero exit code, the
  +  version key is set to the number compiled into the source.
  +  Then continue with startup
If registry access is too difficult here, a simpler implementation 
could be used: just store the number in a .version file.

How do we avoid disturbing the users configuration? Alexandre already 
laid out the plan for this, which is to have HKLM (HKEY_LOCAL_MACHINE) 
devoted to the defaults we cunningly choose for maximum kewlness, and 
HKCU (HKEY_CURRENT_USER) is where the users settings are stored. These 
override the defaults, meaning we can change the default settings by 
altering wine.inf, then bumping the wineprefix version so triggering a 
remerge of the default registry contents.

This means modifying each piece of code where we read the registry to 
figure out a user-configurable option. The algorithm becomes:

* Check the relevant key in HKCU, if it exists use it
* Otherwise, if it's an appdefault, check the same key in HKLM
* Otherwise, use the hardcoded default
In most cases, there's no point in duplicating the points at which we 
can control the defaults, doing it in the code is fine. So, it 
basically means grepping the source to find out where we read settings 
from, and changing them to use HKCU instead of HKLM, perhaps also 
reading HKLM depending on the context of the setting (settings that 
can be used in appdefaults should check both).

I don't know how common these settings are but it might be worth 
having a utility function either in a DLL or inline in a header to do 
this. Registry code isn't complicated but it is tedious and easy to 
mess up, so we might as well reduce code duplication at the same time.

I think the best implementation is to keep the code responsible for 
managing WINEPREFIX in wineprefixcreate, and simply extend this 
program to handle upgrades as well. OK, so the name will be a bit 
inaccurate but let's not change it - users are already discovering the 
new program and getting used to it, no need to modify it now 
especially as it's mostly an internal program.

In the above example the old version and new version numbers were 
passed to wineprefixcreate but most of the time that information 
wouldn't be needed, for instance if we were to introduce fake DLL 
headers we could simply check if they already existed and skip that 
part if so. I think there's no harm in running wine.inf multiple 
times, so we could just do that every time for both creation and upgrade.

I *think* this addresses most of the issues with upgrades, though I'm 
sure Alexandre can think of more :) Potential unresolved problems:

- [How] do we lock wineprefix during upgrade so other processes
  that are run hang about until it's done?
- Currently moving registry keys about is done actually
  in the code itself: we copy it across then print a message
  telling the user to delete the old setting manually. There's
  a fair bit of evidence that some users simply don't spot/understand
  these warnings. Also, we want to allow people to upgrade Wine with
  quite long intervals in between yet eventually this code gets deleted.
  Maybe a better solution is just to have wineprefixcreate unde

Re: urlmon: IInternetSecurityManager

[Boaz Harrosh]

Mike McCormack wrote:
I considered writing a program to generate the code, since it is 
boilerplate code.  The input could be the header file for the class 
factory, and the output the implementation.

Adding more non-standard header files may not be a direction we want 
to head in...

Mike

Rrr, and when fixing a bug or making an Enhancement. all these files 
have to change. Code wizards are not code re-use. Even MS has their ATL 
or MFC to "implement once" all this grunt work. BUT wine no. must redo 
every thing from scratch. A rich wine-Internal implementation framework 
should be the direction to go. A new COM implementation should be an 
instantiation of one macro, or two, and the code itself. Clean fast and 
attractive for new hackers.

Re: MSCMS: new dll

[Boaz Harrosh]

Mike Hearn wrote:
For what it's worth I don't think we should start excluding new DLLs 
from the tree until they reach maturity (what is mature anyway?). If 
they aren't in there people probably won't hack on them.

The flip side is then we end up with a ton of stub DLLs and programs 
that could work in its absence now break. This is a danger whenever 
you add stubs, it's happened with function stubs as well.
Also maybe these DLLs can Just be excluded from the "make Install". 
There should be 2 DLL templates (in Makfile) one for installable DLL and 
one for not-installable. The packagers should make it a rule to only 
include Installable DLLs.

Re: Why is our OutputDebugString a server request?

[Boaz Harrosh]

Shachar Shemesh wrote:
Hi all,
It seems that OutputDebugString is defined in the Win32 API as a set 
of client side operations. In wine, however, it is a server request.

I have not traced it into the server to see whether they carry out the 
same operations or not. However, even if they do, I am wondering why 
we need them? Wouldn't it be better to not do server side things that 
can be done client side?

(http://www.unixwiz.net/techtips/outputdebugstring.html)
Shachar
P.S.
I perfectly understand that obtaining mutexes and waiting on events is 
a server side operation. However, it was my impression that such 
things are best carried out by mimicking the Win32 structure as much 
as possible. Isn't that the case?

Shachar
Hi
I have played with this a bit. Currently, on wine, It is both a client 
side and a server side. if you do WINEDEBUG+debugstr than the output is 
sent client side to the regular debug channel. It than, is also sent to 
the server. If an application like DebugView from SysInternals hooks 
into the server it can receive these messages, and display them. I used 
an home made DebugMon that only hooks WIN32 (NT-kernel has it's own hook 
in kernel) And it worked under wine. I think it did, I didn't play with 
it much. Any way if it does not, It can easily be fixed.  If you want to 
try and it does not work tell me. I'll try to look up the win32 API that 
is used for the receiving of the strings by monitors. I have access to 
code that does that. I'm sure the guys won't mind if I look. It is all 
public API any way.

Free Life
Boaz

Re: Running valgrind with Wine

[Boaz Harrosh]

Mike Hearn wrote:
While we're technically not API stable yet, it's painfully obvious that
1.0 is still a long way away. Stability is a policy rather than a target,
so we've got to start at some point 
 

I totally agree but that should not stop you from doing things Like:
+wine_init_ex( argc, argv, error, sizeof(error), reserve );
+#ifdef __DEEP_DEBUG__
+#define wine_init wine_init_ex
+#endif
(Old API code calls new _ex functions. No point in having 2 of them. But that goes 
with out saying. right?)
The old API is there and a new, freshly compiled programs can see, API for advance 
uses. SO go for the patch. And do keep API Stability.
Free Life
Boaz

Re: iostream and msvcrt?

[Boaz Harrosh]

Scott Snell wrote:
which throws up a world of errors, such as:
In file included from ../stlport/cstdlib:25,
from ../stlport/stl/debug/_debug.c:160,
from ../stlport/stl/debug/_debug.h:418,
from ../stlport/utility:40,
from dll_main.cpp:35:
/usr/include/c++/3.3.2/cstdlib:97: error: `div' not declared
/usr/include/c++/3.3.2/cstdlib:102: error: `ldiv' not declared
/usr/include/c++/3.3.2/cstdlib: In function `ldiv_t std::div(long int, long
int)':
I'm sure its something simple but I'm still not comfortable around
gcc/winegcc.
thanks,
Scott.
 

-Original Message-
From:   Dimitrie O. Paun [SMTP:[EMAIL PROTECTED]
   

adding a path pointing to /include/wine/MSVCRT.
   

No, you shouldn't need that. You just need to make sure you pass
the -mno-cygwin flag to winegcc/wineg++.
--
Dimi.
   

You need to have your stlport/config/stl_wine.h (I based mine on 
stl_mycomp.h, not stl_gcc.h) and change /stlport/config/stlcomp.h to 
include it (based on a WINE_GCC flag). You need to do that because of 
the way STLPort works with headers. you must put a path that will 
Definitely select wine/msvcrt as the source of stdc. I used ../msvcrt in 
the header and than Just fixed up the -I list in makefiles (and the 
WINE_GCC flag or is there a flag that is defined by wingcc).

Free Life
Boaz

Re: iostream and msvcrt?

[Boaz Harrosh]

Scott Snell wrote:
Is that simpler than fixing the MSVCRT headers?  

It is not wine-MSVCRT headers fault, these are pure CRT declarations. It 
is gcc-c++ headers that are heavily dependent  on gcc CRT very 
non-standard headers. So you better go with STLPort.

I have used STLport before
so the idea sounds feasable to me.  I imagine I have to change the
gcc-linux.mak by:
replacing the call to gcc with winegcc,
removing references to GLIBC,
 

Better go with gcc-mingw.mak, as threading and OS is more Windows than 
Linux. See if they have a -nocygwin variant.

adding a path pointing to /include/wine/MSVCRT.
 

Yes exactly. You'll see that you end up with a complete xxx-wine set of 
makefiles and headers.

Anything else?
 

There are some 1-2 defines in the major ARCH headers that go the windows 
way. I remember I had to define a __WINE_GCC__ in makefile and in a 
couple of places where they have this heavy #ifdef this #elseif that - I 
had to add #ifdef  __WINE_GCC__ to point the compiler the windows way. 
But I guess the compiler will show you soon enough where he took the 
wrong turn.

I'll try to dig out that HD anyway Just so we can compare notes. But I'm 
sure you'll manage before I have time to do that.

regards,
Scott.
 

Free Life
Boaz

Re: iostream and msvcrt?

[Boaz Harrosh]

Mike Hearn wrote:
Why are you trying to use G++ with the MSVCRT (Microsoft Visual C++ 
runtime) ? That can surely never work: even if the headers were 
compatible, the ABI used is not.

He meant in a winelib when a winelib links against msvcrt (-nocygwin on 
the winegcc command line). Only the C symbols and  a few C++ (new & 
delete) are exported from wine's msvcrt.spec so only these get linked. 
The rest of the C++ symbols are looked for else where. His current 
problem, though, is Header compatibility.
When you don't use "-nocygwin" than lots of Windows originating code 
(like MFC) does not compile.

Free Life
Boaz

Re: iostream and msvcrt?

[Boaz Harrosh]

Using gcc's c++ libraries will not work with msvcrt. If it will compile 
(which it doesn't) it will not load. (Some circular linking)
Your best bet is STLPort. Check it out. What I have done is a special 
makefiles set with special config.h that compiles and links STLPort over 
msvcrt. I have written to STLPort if they want my changes as support for 
another platform but I never got a response from them. Do you need me to 
dig out the old HD and pack you an STLPort compiled over msvcrt?
You might need to make some changes because it is from before winegcc 
times,. Going strait for gcc. and maybe some wine stuff changed since than.

Scott Snell wrote:
Hi All,
Thanks to everyone who has helped me with winelib, so far most things are
going really well!  However here is an issue I cant solve - iostream and
msvcrt.  Here is an example file:
// test.cpp module
#include 
#include 
int test()
{
   return 1;
}
If I compile it using:
wineg++ -c  -mno-cygwin -I/usr/local/include/wine/msvcrt -o test.o test.cpp
or 

wineg++ -c -I/usr/local/include/wine/msvcrt -o test.o test.cpp
I get a multitude of errors such as:
In file included from /usr/include/c++/3.3.2/iosfwd:46,
from /usr/include/c++/3.3.2/ios:44,
from /usr/include/c++/3.3.2/ostream:45,
from /usr/include/c++/3.3.2/iostream:45,
from test.cpp:2:
/usr/include/c++/3.3.2/i386-redhat-linux/bits/c++locale.h:53: error:
`uselocale' was not declared in this scope
In file included from
/usr/include/c++/3.3.2/i386-redhat-linux/bits/c++io.h:35,
from /usr/include/c++/3.3.2/bits/fpos.h:44,
from /usr/include/c++/3.3.2/iosfwd:49,
from /usr/include/c++/3.3.2/ios:44,
from /usr/include/c++/3.3.2/ostream:45,
from /usr/include/c++/3.3.2/iostream:45,
from test.cpp:2:
/usr/include/c++/3.3.2/cstdio:167: error: `snprintf' not declared
/usr/include/c++/3.3.2/cstdio:168: error: `vfscanf' not declared
/usr/include/c++/3.3.2/cstdio:169: error: `vscanf' not declared
/usr/include/c++/3.3.2/cstdio:171: error: `vsscanf' not declared
So whats my newbie mistake?
thanks,
Scott.
 

Re: Adventures in serial port.

[Boaz Harrosh]

Scott Snell wrote:
 However I have struck a problem.  My windows program
code links in a .lib file that is provided by a third party.  Can I link
this library file into my winelib project, and if so how? I cant seem to
find any recent discussion on this topic
 

One way I know is to wrap the .Lib in a .DLL on windows with MSVC or 
MinGW. Than use the DLL in your winelib.
On the winelib side you have to make a .SPEC file for your windows DLL.
Look in previous threads and  in winelib documentation for how to make a 
.spec file of your dll, and how to link to it.

If you use MSVC do use a .DEF file because winebuild used to have 
problems with "__declspec(export)" functions exported from DLLS. (maybe 
it was fixed I'm not really up to date)

Free Life
Boaz

Re: Different X Displays and Wine

[Boaz Harrosh]

Alexandre Julliard wrote:
That's not supported at the moment. You can run apps on two different
displays by using a different WINEPREFIX for each, so that they don't
share the same wineserver. Using different users would work too.
 

Since I started to research this I was terrified this would be the answer.
 I Thinks It should be stated, in bold letters, at the beginning of the 
user guide. I kind of have my neck on the line here. The reason I was 
contracted for this job was so we can run 100s of users off of a modest 
Linux Server room. With cheap x-terminals and old Win98 machines running 
an X-Server.
 What about the todo page is that on the todo for 1.0? Is it on any 
todo List?

Back to business: What you are saying is that I need to run a separate 
wineserver instance for each different $DISPLAY I want to support. This 
can only be done with WINEPREFIX or with a different user. Now, I need 
this to have the minimum Impact on the server so I have some questions 
if any one can help me I will most appreciate it:

[1] Can I Just "ln -s" the .wine folder and than point WINEPREFIX to the 
new link so a new wineserver Instance will be lunched? Or do I need a 
separate copy.
(something like> ln -s .wine .wine$DISPLAY ;WINEPREFIX=.wine$DISPLAY 
wine ...)
OK, I tried, this does not work! what does work is (# mkdir 
.wine$DISPLAY ;ln -s .wine/*  .wine$DISPLAY/) have a real directory with 
every thing there linked to the real thing.

[2] If yes for 1 would the Linux Kernel share my code segments across 
wineservers? (Probably yes).

[3] When is the $DISPLAY sampled by the wineserver. On first application 
startup, on first window created, or on server load? If I make the 
wineserver stay in memory (-p) will it re sample the $DISPLAY when a new 
app is started after all the old ones exit.

[4] Can I pre-run a wineserver and than on connection point wine to use 
a specific (next) wineserver Instance? IF not will it be hard to 
implement and will it be accepted into the tree? If yes and it is 
accepted can it be made automatic when ever $DISPLAY is changed 
(different). (Instead of bailing out a few moments later)

[5] How much effort is it to Implement such a support? Where do I start? 
Did any one have any thoughts on how this should be implemented? I was 
always in the notion that the x11drv was an In-process implementation 
creating a relationship between the wine-process and the x subsystem it 
is running under, only registering information under the server. Proof 
of that, I thought, was the current lack of cross process windowing. 
Well I was wrong. What is the basic flaw in Windows API that prevents it?

[(DWORD)-1] What does Codweavers do on their Server product. How do they 
server concurrent Office users?

Free Life
Boaz