wine-devel

wine-devel@winehq.org

3 participants
84464 discussions

Re: My WineHQ menu structure proposal - counterproposal
by Andreas Mohr 03 Nov '02

03 Nov '02

On Sun, Nov 03, 2002 at 09:43:40AM +0000, Keith Matthews wrote: > On 02 Nov 2002 23:51:01 -0600 > "Jeremy White" <jwhite(a)codeweavers.com> wrote: > > > > > > So, I propose the following instead: > > > > First, this assumes that we use Jeremy Newman's idea of a rotating > > screen shot on main page, and continued prominence of the news. > > > Ugh. Why do people insist on thinking that 'sexy' images are the be-all > and end-all of web design. When I go to a web site I want _information_, > not some bandwidth-soaking image that gives nothing useful. Have > screen-shots for those that can't see beyond them, but don't put them on > the home page, put a clear link to them. > > A lot of people are still on analogue dial-up links, they don't > appreciate large images increasing download time, I'm on DSL and I > switch off images to get faster downloads. But a screenshot showing a sufficient amount of information should only have about 5 KB or slightly more (I hope :). Also add a subtitle describing the current screenshot, and then 5 KB "ought to be enough for everybody" to be interested about a particular screenshot. > Other than that you may want to promote 'legal' to the top level, if > only to reduce the number of menu options for item 1 at the next level. > 9 is as many as one should have and 7 is a better limit. Yep, 7 is the standard amount of things you can manage/grasp. -- The Declaration of Software Freedom: http://freedevelopers.net/freedomdec/index.php

1 0

header layout agreements
by Christian Neumair 03 Nov '02

03 Nov '02

As the topic suggests this thread focusses on the layout of our existing wine header code. Maybe it sounds a bit pedantic but it's essential to have unified guidelines all developers should follow: Dimitrie O. Paun <dpaun(a)rogers.com> already did a great job [1]: He just added additional comments to a common header describing exactly what still remains to do. We should have a unified header which contains at least: /* * ... * ####### HEADER (normally license terms) ######## * * DESC * This DLL manages <...> * * FUNC * -- 1st function * Internal FAN flags: * FAN_TASY - specifies our imaginary code * FAN_TASTIC - this array stores some code (not yet * implemented) * -- 2nd function * -- 3rd function (not yet implemented) * -- etc. (* * Optional : * * TODO * -- 1st function: implement FAN_TASTIC. * -- yet another item * * BUGS * -- 1st function: we need to handle a call without FAN_TASY being * passed * -- plain old item */) We're already providing detailed information on parameters, return values etc. above many functions so adding this to the file header would just bloat it. Comments on that, please :) regs, Chris [1] http://www.winehq.com/hypermail/wine-patches/2002/10/0343.html

3 2

Strange problem on serial port
by David D. Hagood 02 Nov '02

02 Nov '02

There seems to be a strange problem related to the serial port. Specifically, when running Delorme AAA MapNGo 4.0, and attempting to use GPS navigation, it is unable to communicate with the GPS device. On stderr Wine is printing out RtlNtStatusToDOSerr - unable to map 00000102 This only happens when the GPS device is connected and sending data, otherwise no error is printed. I know that the device is sending, because Minicom will show the data stream from the device. This also leaves out permission problems as both Wine and Minicom are running with the same permissions. A bit of grepping through the code indicates the likely error code is STATUS_TIMEOUT. Could it be that the serial I/O routines are incorrectly returning STATUS_TIMEOUT to the calling program when data was read? Additionally, I have another Windows program that accesses the serial port without problems - could it be that second program is ignoring the timeout error, while the first is not?

1 0

Wine 0.8 TODO v0.2
by Dimitrie O. Paun 02 Nov '02

02 Nov '02

This will probably get renamed to Wine 0.9 TODO, after Alexandre's clarification, but I haven't changed the name just yet, to avoid confusion. Once again, what I mean by 0.8: -- Users can start using Wine -- works well for a fair number of apps -- no MS DLLs required (from real Windows) -- User facing stuff (website, docs, etc.) are in a decent state, to avoid scaring them away What is NOT in 0.8: -- stable server protocol: no binary compatibility -- DLL separation: ditto That being said, this is my initial list. Comments, flames, suggestions, are appreciated. A. WineHQ work (Beta at: http://lostwages.winehq.org) 0. Website redesign Jeremy Newman <jnewman(a)codeweavers.com> 1. Reorganize the navigational menu There is a proposal being discussed on the list 2. Create some really sexy screenshots -- one app per screenshot, avoid cluttered desktop -- minimize size, if possible by using 'Positioned Color Dithering' 3. Rework the FAQ interface (static HTML, a la http://www.dvddemystified.com/dvdfaq.html, all on one page, with a clickable question list at the top) Agreed on the list. Should be written in SGML, so we can output all sorts of formats. Which means we need layouts, etc. Any takers? 4. Enlist some 'official' distribution maintainers (at the minimum RedHat, Suse, Mandrake, Debian) 5. Create nice page with apps that run virtually flawless They should not require MS dlls, tricks, etc. to run Small explanation, screeshot, optional link to download page, such as Tucows. Carlos <clozano(a)andago.com> is running with it. B. Documentation work Andy, take it away! :) 0. We need to figure first _what_ is out of date. C. Wine configuration 0. Merge configuration into the registry 1. Write control panel applets for editing it 2. Have decent defaults so we can start control panel without prior configuration 3. Have wizard like app to autoconfigure wine WineSetupTk proposed by Jeremy White <jwhite(a)codeweavers.com> 4. Make Wine's DLLs register themselves to avoid manual merging of the winedefault.reg 5. Write .inf script to setup a new Wine installation 6. Have a wineboot script for RunOnce stuff D. Stabilize utilities 0. Get rid of the init directive from .spec files Alexandre Julliard <julliard(a)winehq.com> volunteered 1. Make sure the .spec file format is fairly stable Any other things that may need changing here? 2. Ensure the various utilities' options are stable Anything here? E. Important fixes 0. Window management rewrite, so we can install apps in managed mode. -- Dimi.

3 6

Re: Wine FAQ - call for a volunteer
by Dimitrie O. Paun 02 Nov '02

02 Nov '02

On November 2, 2002 02:39 pm, Tony Lambregts wrote: > I will volunteer to take on the task of taking it from text and > converting to sgml. It needs to be SGML. Do we have styles for > <question> and <answer> already? ... Just Checked No... That's cool, but more importantly we need, styles to convert the SGML to the HTML of our choice. Help here would be _greatly_ appreciated. -- Dimi.

1 0

Re: WineSetupTk
by John K. Hohm 02 Nov '02

02 Nov '02

> First off, thanks for the offer -- it's generous, and very > useful IMO. It certainly sounds interesting, and I would like to > take a peak at the code. The big problem I have with WineSetupTk > it's that it's written in Tcl/Tk (I suppose). I don't know the > language, and I don't care to learn it. Moreover, I think Wine > should use itself for such tools, so we get to use all the nice > controls we have <g>. One thing that I'd like to see is a > programs/winesetup utility that's based on WineSetupTk, but > it's written in C, with the Win32 API & Controls. I believe Alexandre plans to have Wine configured via the registry eventually. Then it would probably make sense to have a C program that acted as a control panel applet and did what WineSetupTk does, but in a dynamic fashion using the registry APIs. Until then I would expect a C version of WineSetupTk to be rather ugly from having to deal with much text config parsing and manipulation.

2 1

Re: Today wine's compatibility with 20 popular apps from tucows
by Carlos Lozano 02 Nov '02

02 Nov '02

El sáb, 02 de nov de 2002, a las 16:54, Keith Matthews escribio: > > I have taken the 20 first entries of the top 100 tucows list, > > except that some entries has been removed, mainly antivirus > > and programs what need other different program to work. > > (URL: http://tucows.uam.es/toppicks.html) > > > Do we really want things which have serious native alternatives. > > The ones I am especially looking at are Ws-FTP and putty. Most distros > have a FTP server, even if it's the grotty WU-ftp with it's bad > security record, and all the sensible distros are shipping OpenSSH. It is the same that when you are doing a videogame console emulator. You don't start testing the comercial games first, you start with simple demos, when you will get the basic working, then start with more complex one, and so. The important is not run this applications, the important is that sure that the authors of this applications have used features what are the base of other more complex. So if this features are working correctly, it will be easier run more complex software in the future :) Regards, Carlos. -- ___ _ \ | / Infraestructuras | . |._ _ _| | ___ ___ ___ http://www.andago.com | || ' |/ . |<_> |/ . |/ . \__ GNU/Linux |_|_||_|_|\___|<___|\_. |\___/ _ \ __|\ \ / Carlos A. Lozano <___'/ | \ -_) __/\__ \ > < -_) [ carlos.lozano(a)andago.com ]\___|_| ____/ _/\_\___| [ calb(a)epsxe.com ] http://www.epsxe.com

1 0

Re: Today wine's compatibility with 20 popular apps from tucows
by Joerg Mayer 02 Nov '02

02 Nov '02

On Sat, Nov 02, 2002 at 04:54:47PM +0000, Keith Matthews wrote: > Do we really want things which have serious native alternatives. The make good test cases and are good as demo applications too, because people who use Windows may know theses already and the list is obviously not a list put together for that purpose because the apps have been selected by Downloaders at tocows. Ciao Jörg -- Joerg Mayer <jmayer(a)loplof.de> I found out that "pro" means "instead of" (as in proconsul). Now I know what proactive means.

1 0

Plea to fix winelib COM vtable bug
by Matthew Bloch 02 Nov '02

02 Nov '02

This is a summary of my recent probs with Winelib in the hope that someone who knows the COM stuff can fix them quickly, because hacking through the jungle of include files and definitions is hard work In short, I've built the latest wine cvs with the ICOM_MSVTABLE_COMPAT flag set in include/wine/obj_base.h, so each vtable has two dummy words at the start for g++'s benefit. I then added these statements to the start of my WinMain to cause a segfault: IDirectDraw* dd; DirectDrawCreate(0, &dd, NULL;) and for good measure, wrapped the call to IDirectDraw7_QueryInterface in DDRAW_Create (which is where the segfault occurs) in ddraw/main.c with these two warnings: WARN("about to call IDirectDraw7_QueryInterface vtbl size = %d\n", sizeof(DDCF_Vtbl)); hr = IDirectDraw7_QueryInterface(pDD, iid, lplpDD); WARN("called IDirectDraw7_QueryInterface\n"); and when running the program, the trace clearly shows that the Release entry point is being called instead, and crashing, though the vtable is the expected size (5 entry points, plus 2 dummy dwords): warn:ddraw:DDRAW_Create about to call IDirectDraw7_QueryInterface vtbl size = 28 warn:ddraw:DDRAW_Create offset is 12271064 trace:ddraw:Main_DirectDraw_Release (0x403a7c70)->() decrementing from 1. warn:ddraw:Main_DirectDraw_Release doing final release Looking at the pre-processor output from compiling ddraw/main.c, I can see that IDirectDraw7Vtbl type has the two extra words grafted onto the front, as it should: struct IDirectDraw7Vtbl { long dummyRTTI1; long dummyRTTI2; HRESULT (__attribute__((__stdcall__)) *QueryInterface)(IDirectDraw7* me, const IID* const a, LPVOID* b); ULONG (__attribute__((__stdcall__)) *AddRef)(IDirectDraw7* me); ULONG (__attribute__((__stdcall__)) *Release)(IDirectDraw7* me); ... The problem seems to be that the call is offset not just by two table entries, but four. Somewhere in that jungle of macros, the "vtable base adjustment" of +2 is being applied twice, I'm sure of it. But I'm buggered if I can find out where this is happening; I'm still looking but it's slow progress and I believe it's a winelib bug. Any suggestions on how to fix it would be welcome. cheers, -- Matthew Bloch Bytemark Computer Consulting Limited http://www.bytemark.co.uk/ tel. +44 (0) 8707 455026

3 4

Re: dlls/msvcrt: msvcrt-popen-2.diff
by Jaco Greeff 02 Nov '02

02 Nov '02

On Sat, 2 Nov 2002 10:56:02 -0500, "Dimitrie O. Paun" <dpaun(a)rogers.com> wrote : > On November 2, 2002 10:41 am, Jaco Greeff wrote: > > +#define POPEN_WCMD_EXEC "C:\\Windows\\System32\\cmd.exe /c" > > Do we need this hardcoded path here?!? What about the COMSPEC > idea that Francois suggested? I'm still trying to get that one to go. As soon as I've got it, I'll submit the small change. <snip> > > + else > > \ > > + CloseHandle(hHandle); > > What's up with all the macro abuse? :) We don't like cpp that much! ;) > Please, try to do things without macros, it can't be that bad. And everybody is a critic ;) I really hate duplicating code in any function. I'd rather use a macro which make the function 1. more readable, 2. shorter :) I would potentially rather more it to it's own header file than doing the cut-n-paste thing inside a function... Would it be 50% ok with macro abuse in a seperate header file? Greetings Jaco

2 1

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

wine-devel