Enclosed is a patch (diff to 2001.12.26 snapshot) which impements
stdio buffering in msvcrt. Since I cannot make Visual C binaries
could anybady with Visual C++ test it?
I have testet it with mingw32 and I incude my test program (iotst.c).
The program prints a line indicating which test it is making
and then complains about failures.
Comment 1: current builtin msvcrt fails test1 (and few other
as a consequence). Some native versions of msvcrt fail test 8.
Comment 2: I wrote the test the way naive programmer would wrote
it (IMHO). Now I think that for a testing framework we need an
assert-like macro to make checking and printing code shorter
and to have uniform printouts. I ommited some tests that require
multiple processes (expandig file while it is read, checking that
stdio buffers got flushed at exit) - I guess that doing such
test in portable way is quite tricky.
--
Waldek Hebisch
hebisch(a)math.uni.wroc.pl or hebisch(a)hera.math.uni.wroc.pl
hello everybody,
just want to let everyone know that i (shane shields) have joined the mailing
list and downloaded the latest cvs.
what i want to know now is what can i do i have some c experience but mostly
dos (and some windows), vb (but i dont think its relevent) and i know the
windows os quite well. as i converted to linux 8 months ago and totally
removed windows i would like to help with wine development with the aim of
not having to use any proprietry dlls at all (to do with the core os that
is). i have looked at the 20011226 version and noticed that the ole
functionality is virtually nonexistant. is anyone working on that? or is
there a better way to cut my teeth with wine programming. suggestions,
directions and flames welcome. just remember that i am relatively new to
linux programming.
looking forward to joining the community
Shane Shields
_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com
"Mark G. Adams" <mgadams(a)sympatico.ca> writes:
> I came across a program which imports a function from winspool.drv via
> ordinal instead of via name. Now back in February, a patch from Huw Davies
> was committed which removed all the ordinals from the spec file for winspool
> (see http://www.winehq.com/hypermail/wine-cvs/2001/02/0016.html). I don't
> know what the reason was (maybe some were wrong?), so I've attached a patch
> which re-adds the ordinal for the one function this program requires.
What app is that? None of the winspool.drv I checked have
PrinterProperties at ordinal 201, so I don't see how this could work.
Or does it just want to have something there? does it work if you put
a stub at 201 instead of PrinterProperties?
--
Alexandre Julliard
julliard(a)winehq.com
> This patch changes the NLS currency of all Euro countries to
> use the "EUR"
> as international currency and the euro-sign (iso-8859-15,
> character 164).
Hmm. While I'm do not doubt that some users of Wine might find this useful,
Wine is supposed to do what Windows does and if Windows does something
wrong Wine usually should as well.
If I'm not mistaken the .nls contains that default values. It is
entirely possible to change the currency and such in the registry
to specify things differently for each user.
That said I would find it unlikely that this patch would cause any
serious problem. After all, as I said, the user can specify whatever
currency it likes after the defaults have been set and every application
is supposed to be able to handle it.
So I do not really oppose the patch. It is more the principle I'm intrested
in:
Under what circumstances should Wine change the behavior
if Windows does something in the wrong way?
On Thu, 3 Jan 2002 ccrayne(a)crayne.org wrote:
> - /* We will use a snippet of real mode code that calls */ +
> /* We use a snippet of real mode code that calls */
> /* a WINE-only interrupt to handle moving the requested */ -
> /* message into the buffer... */
> + /* message into the buffer...
...
> - INT (WINE-only interrupt)
If that's what you need, I suggest allocating a DPMI Real-Mode Callback
thunk using DPMI_AllocInternalRMCB(). (There's an example of how to use it
in dosaspi.c... you give it a Wine-implemented function, and it returns a
real-mode address that DOS apps can use to call it... the only thing to
keep in mind is that it's the Wine function's responsibility to pop the
real-mode stack)
Hi Martin,
The console doesn't use an fd, so no fd will be fetched in
FILE_GetUnixHandle. (have a look at server/console.c)
Mike
> Btw,
>
> in the code in ReadFile() / WriteFile() handling consoles,
> shouldn't there be a
> close (unix_handle)
> statement before calling ReadConsoleA() / WriteConsoleA() ?
>
> Martin
------------------------------------------
mailto:[email protected]
ph +82 16 430 0425
__________________________________________________________________
Get your free Australian email account at http://www.Looksmart.com.au
Hi,
I've been looking into this function, trying to work out why ms office 97
can't install under Wine. (I've also been looking at the handling of
command-lines when new processes are spawned, as office's setup program
spawns a process called acmsetup with a string of command-line options, and
it seems that wine manages to insert an extra " at the end of the command
line.)
What I've found though with the SHGetSpecialFolderLocation, is that it seems
to me that it is designed to allow the caller to pick an arbitrary value for
the CSIDL, and that this will cause windows to create a new CSIDL. As the
function's implementation currently stands, it has a hard-coded table of
possible CSIDLs, and rejects calls with unknown CSIDLs.
Has anyone else looked at this function, and does anyone have any comments or
suggestions on ways to address this? I'm thinking that these values probably
need to go into the registry, or something, rather than being stored in the
code...
regards
Chris Green
While doing research for my site on the Microsoft
antitrust trial ( http://www.kegel.com/remedy/ ), I
came across a nasty little EULA for a product called
MSNBC News Alert. The EULA is at
http://www.msnbc.com/tools/newsalert/naeula.asp
and says
> MSNBC Interactive grants you the right to install and use
> copies of the SOFTWARE PRODUCT on your computers running validly
> licensed copies of the operating system for which the SOFTWARE
> PRODUCT was designed [e.g., Microsoft Windows(r) 95; Microsoft
> Windows NT(r), Microsoft Windows 3.x, Macintosh, etc.].
It'd be nice to know how close Wine is to being able to
(a) install and (b) run this on a fake windows installation,
as this may have some bearing on whether Microsoft is
damaging anybody with this exclusionary EULA.
(Besides, how could I resist? That EULA practically begs to be disobeyed!)
So I downloaded it from
http://www.msnbc.com/tools/newstools/d/news_alert.asp
and ran it, but it failed with the dialog box
"News Alert and Windows were unable to start your
default browser to access the following URL..."
Can anyone have a look at what's wrong (presumably Wine
doesn't implement browser control, or I don't have a browser
registered?)
I'm running Wine release 20010731 (my, that's old!)
The output of wine -debugmsg +all is at
http://www.kegel.com/wine/newsalert/log.bz2
and is 328KB compressed (200 MB expanded!)
I can't see anything obvious, but then I'm out of practice.
(You probably just want to download the executable and
try it yourself.)
Thanks,
Dan Kegel
Hi,
I would like to establish two Wine tasklists in Wine's bugzilla.
* the first list would contain the items listed in my previous 'Call
for Volunteers' emails. This would make it easier to keep track of
these tasks.
* the second list would contain more complex and general items like
'DCOM support'.
For the first list, refer to my previous 'Call for Volunteers'
emails. I think I will start it from there and we can update it after
that. For the second list, I included a first draft below. I would like
your comments on it, especially with regard to the status of some of
these items, and suggestions if you see missing items.
I know we already have a 'Wine 1.0' and 'Wine 1.x' tasklists'. There
may be some overlap but I think the intent is different.
* My intent with these two new tasklists is to advertise what we want
to do to potential contributors. So the idea is to then add a page to
the WineHQ web site that would list all the ways one can contribute to
Wine: maintaining an application entry in the Application Database,
helping users on the mailing lists, buying Wine based applications, and
of course contributing code. And for this last item, these lists would
provide a good starting point, both for developpers with little time and
for developpers who want to invest themselves more heavily in Wine.
* Then unlike the 1.0 and 1.x tasklists, these new lists would not be
tied to a specific Wine release or date.
I hope to produce a draft of this web page in the coming days. In the
meantime let me know if I missed things in the list below. For each item
I tried to indicate the rationale behind the task, and point to the
corresponding bugzilla report if there is one.
Wine tasklist
-------------
* Make the registry loadable on demand
- when working from a Windows partition the registry is big.
- this causes wineserver to allocate a lot of memory
- this has a big impact on startup times
- a 'database' based registry may be more robust
* Rasterizer
- to paint into a DIB we have to copy the IB contents into an X
bitmap, call X functions to modify the bitmap, often only to have
to copy the result back to the DIB when the application tries to
read it. Imagine it for eash SetPixel operation!
- a rasterizer would be able to perform these operations directly on
the DIB and thus provide better performance, at least in some
situations.
- it would also provide better color accuracy: the X server often
only supports a few bit depths so that if the application works on
a 24bpp DIB but the X server is in 16bpp mode, 3bits are lost per
color component.
* Cross process messages
- used by many applications
- needed for DDE (bug 95)
- Alexandre, you worked on this recently, right? Is this working now?
- See bug 93
* Out of proc COM
- Needed for Installshield 6
- Would probably help with at least some functionality of a host of
other applications
* DCOM support
- same as out of proc COM but network transparent
- should be interoperable with Microsoft's implementation so that, in
a company setting, processes running in Wine can connect to servers
running on whatever Windows server are present.
* Better multi-user support
- how to get per-user registry files
- how much per-user setup is really necessary?
(create a '.wine' directory, create per user registry files, who
does that, ...)
- is it possible to share a single read-only 'c:\' drive? What do
we need to get parity with an NT environment?
- is it possible to share a read-only 'system.reg' file?
- what is the impact of a 'load on demand' registry? Could we share
a single registry server?
- what would be necessary to share a single
- there are many options that need to be investigated and
documented...
* UNC path handling
- for drives '\\.\e:', devices
- for network paths
- there's been a patch related to this recently but I believe it does
not cover all cases
- integrate with Samba to handle network UNC paths
- provide a way to mount/unmount drives at runtime, especially
network drives. One should be able to disable this in the config
file (for security reasons).
- Support for 'persistent' mounts... will require modifying the way w
specify which drives are mounted where.
- provide an applet to mount/unmount drives while Wine is running.
* Native Alsa support
- Alsa is the future of sound in Linux: should be integrated in 2.5
- Could it offer capabilities that OSS does not offer?
- Other platforms may not support Alsa any time soon so we must keep
OSS too
- Anti-rational: Alsa includes an OSS compatibilty mode that seems to
work pretty well
- see bug 324
* aRts support
- On an OSS system when the aRts daemon is running Wine cannot access
the sound device
- aRts makes it possible to send the sound other the network. This
kind of functionality is great for a thin-client environments:
setup a server and have the sound sent to each terminal ("You've
got mail" ;-). Supporting aRts in Wine would let it integrate
perfectly in such an environment.
- this could either be native support, or making Wine compatible with
artsdsp. The current problem may be related to the -Bsymbolic link
option.
- see bug 325
* ESounD support
- Same thing as for aRts
- see bug 326
- Making Wine compatible with artsdsp may also make it compatible
with esddsp (and vice versa).
* Write a regedit replacement
- used by some installers to create registry keys
- we can limit the functionality to just that although since Wine has
a registry we should probably provide a tool to browse/edit it.
- will be more important once we have a database based registry for
the load on demand functionality
* Write a regsvr32 replacement
- used by some installers
* Fix the desktop mode
- If a process running in desktop mode start another, the new
process creates a new desktop
- the background is black
- one cannot start a specific application in desktop mode. You have
to modify the config file.
* Compile with STRICT on
- better type safety
- reveales all the 16/32bits hacks
- see bug 90
* Dll separation
- to allow us to swap native dlls in and out with less problems
- to make the dlls more independent of each other and make it easier
to treat them as independent projects
- see bug 96
* HEAP_strdup* removal
- Alexandre said some day that they will go away
- Part of the dll separation?
* Move the winsock16 code to wsock32
- winsock16 is more related to wsock32 than to ws2_32
- ws2_32 is the new API. This would leave us with a clean 32bit
implementation of the new API that is not encumbered with 16bit
hacks.
* Check .spec file completeness
- we need complete spec file to know where we stand
- determine what's new in WinMe, Win2000, WinXP
- check that the ordinals/absence of ordinals is correct
- I have scripts that can be used as a starting point
* Winedbg expression handling
- when modifying the contents of a variable there can be mixups where
the debugger modifies its own memory instead of that of the
debugged process.
* Winedbg g++ 3.0 support
- The debugging format and the ABI changed in g++ 3.0 and winedbg
does not support the new ABI.
- This prevents debugging of C++ Winelib applications
- This is especially troublesome for MFC Winelib applications
- Eric, you worked on this recently, do you know if this is a thing
of the past or is it possible that there are still problems (I did
not test recently)
* Better memory allocator
- some memory allocation/release patterns cause the current allocator
to be relatively inefficient
- see threads on wine-dev (Ove/Gav hit this problem)
* Winelib richedit support
- one of the things needed by MFC
- the API seems at least partly supported, but the headers are very
incomplete
- see bug 330
* Visual C++ project support
- make it possible to generate a Winelib project from a Visual C++
project
- this should be done by extending winemaker
- see bug 61
* Specify how to compile and package the MFC
- many applications use the MFC. To make Winelib useful it is
necessary to make it easier to compile the MFC and MFC-based
applications
- winemaker has some support for the MFC. But it makes suppositions
about how the MFC were compiled (library names, etc.). So it is
necessary to document how to get something that works well
- see bug 110
--
Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/
145 = 1! + 4! + 5!
