Re: WineHQ on CMS/Framework
We had same question in the ReactOS web site. We have our own in-house developed CMS called RosCMS now, however there is a strong desire to change it to something maintained by 3rd party, so Drupal and Typo3 were considered. Two prototype websites were made, one using Drupal7 and another one (more recent and more complete) using Typo3. What's important is that we have a substantial set of interconnected services too: * JIRA (formerly Bugzilla, integrated authentication with the main website) * Mailing lists (no need for integration) * FishEye as a source code browser (integrated) * GIT mirror with source code browser (no need for integration) * Doxygen source code browser (no need for integration) * MediaWiki (fully integrated, single sign-on) * Forums (fully integrated, single sign-on) * Compatibility database (integrated with RosCMS, single sign-on, however it's ported neither to D7 nor T3) * Test manager (http://www.reactos.org/testman ) * Paste service (fully integrated to prevent spam, single sign-on) * Trunk builds download manager (http://www.reactos.org/getbuilds/ ) If any help is needed, let me know, would be glad to share. Best regards, Aleksey Bragin. On 22.09.2012 7:32, Kyle Auble wrote: After working on the wiki for a while, I finally wanted to ask about possibly moving WineHQ to a CMS or web framework. First off, while there are a couple of mentions on the wiki and mailing lists, is there still much interest in doing this? If there is, I think the second question is which kind of system do we want to use? While http://wiki.winehq.org/WinehqDesign mentions Drupal, which has a lot of plugins and features for easy editing, I've read that a CMS can become a hassle if your website needs to do more complex things than serving regular chunks of content. WineHQ provides a bug-tracker, a forum, a wiki, mailing lists, source-code browsers, and other tools besides static content, with lots of interconnections between them. If we did go with a web framework, we could still probably run a CMS on top of it for the AppDB and static pages.
Re: user32: Implement support for getting class data GCLP_HBRBACKGROUND on other process window
Some comments regarding this patch. It's a beginning of a series of patches aimed to improve the desktop mode of Wine, including support for a real Explorer-alike environment (which is Martin Fuchs' explorer at the moment). So this patch implements required GetClassLong functionality of getting background brush handle of another process window's class. I think other apps also require this (e.g. I saw a similar bug in Wine's Bugzilla regarding Microsoft Project 2000), but it is not so critical as in Martin's explorer. WBR, Aleksey Bragin. On Sep 17, 2010, at 10:13 PM, Aleksey Bragin wrote: <0001-user32-Implement-support-for-getting-class-data-GCL.patch>
Re: Wine on cygwin now compiles!
Is there any real, practical interest in Wine on Windows? I've been making some progress in this direction recently (though I think my approach would be to have a ported, NT-version of wineserver.exe which just uses native functions of the OS instead of emulating them over cygwin, which emulates those features using its own code once again; discussable anyway). WBR, Aleksey Bragin. On Jun 17, 2010, at 12:19 AM, Steven Edwards wrote: On Wed, Jun 16, 2010 at 4:04 PM, Roderick Colenbrander wrote: I don't expect Wine itself to ever work on cygwin. Last year I asked AJ about it and there are some special file handle features which are needed. This stuff is supported in SUA but at least in the Vista version this was broken. They MIGHT have fixed it for Win7, so if Wine can work on Windows it would need Win7 but still you would need a version which supports SUA (which are Ultimate and perhaps some business version). If anyone is sufficiently interested in the sendrecv message sockets over file descriptor stuff (I know I am not anymore) there may be an archived email with a regression test I found showing the problem. Even though it was now listed as a supported operation, it kinda sorta worked in limited cases under Server 2003 and hung in others which Wine stress. I don't even recall all of the details at this point but it culminated in me presenting my findings to the SUA team developers and them saying 'that's nice, call our support to file a bug report'. Since I could not actually file the bug report myself online and calling Microsoft support is like a $200 (even if they do issue a refund or not charge your CC if it's a new real bug), I decided to waste no more time with it. -- Steven Edwards "There is one thing stronger than all the armies in the world, and that is an idea whose time has come." - Victor Hugo
Re: Graphics Driver Interface Standardization
I'm doing my own (non-X11 and not a Quartz one) version of a graphics/
user driver, and the interface is quite stable. Only a few minor
changes were done over the period of ~6 months.
Also, if I don't mistake, the specific winex11 calls from explorer
are not needed anymore.
WBR,
Aleksey Bragin.
On Apr 21, 2010, at 12:40 AM, Charles Davis wrote:
Hi,
I'm getting ready to implement the Quartz Driver. For those of you who
don't know, this is a special graphics driver that only works on
Mac OS
X, and uses its native Core Graphics (aka, Quartz) system to draw.
But before I can do this, there are two things that need to be done:
1. Wine currently assumes that the current graphics driver is the X11
driver. It directly GetModuleHandle()'s winex11.drv in order to call
driver functions. This needs to be fixed.
2. The driver interface needs to be standardized.
I can fix the first problem by adding a Wine-specific export to GDI32,
then updating all the winex11 clients to call this function, but the
second problem will make writing a non-X11 driver problematic. The GDI
and USER interfaces are already somewhat standardized, but the reason
many clients call winex11.drv directly is to call the "Thread-Safe
X11"
locking routines. Also, Explorer calls winex11 to create the
desktop and
notification area ("systray") windows.
Therefore, I propose this interface. It's largely based off of
winex11,
but with some small modifications. It's attached to this mail. What do
you think of this?
And don't tell me that we need a DIB engine before I get started on
winequartz. I intend to use Mac OS X native APIs (like Core Image) to
accelerate DIBs, in much the same way winex11 uses Xrender.
Chip
Arwinss
Hello, I would like to present my project here too, because I think this information will be interesting for Wine developers. At least, I have not seen anyone gone that far using Wine code. I came up with an idea to create an alternative Win32 subsystem, which would be targeted to NT-alike OSes: Windows NT family and of course ReactOS, based on Wine as much as possible. Detailed presentation with explanations is attached, along with links to some more information. Briefly, what I did: gdi32.dll - source code is nearly unmodified from Wine, but compiled in ReactOS tree, into a real PE DLL. user32.dll - source code is nearly unmodified from Wine, but compiled in ReactOS tree, into a real PE DLL. What about Wineserver, you would ask? SERVER_START_REQ and related macros are rewritten to perform a syscall to win32k.sys (more about win32k.sys below). Server protocol is the same, but of course many requests aren't need. winex11.drv - this is the one if you want X Server to be your interface. This is unchanged Wine source code, again compiled inside a ReactOS source tree into a PE DLL winent.drv - an alternative user/gdi driver, which mostly forwards all calls into a kernel mode graphics engine located in win32k.sys (which is compatible with Windows video drivers, so all acceleration could be used). win32k.sys - kernelmode counterpart of the new Win32 subsystem, contains graphics engine, user server which is based on a small part of platform-independent Wineserver source code adapted to kernelmode, and a simple window manager which calculates visible regions for windows and manages window showing/hiding. All other parts are used from the host OS (be it Windows, or ReactOS). The most funny thing is that this subsystem actually started to work! (I attached a few screenshots in the presentation). There are still some bugs making Arwinss not really usable at the moment, but I'm inviting all developers to participate and help me bring it to a fully usable condition, so that it supports at least all apps which Wine supports plus those which Wine doesn't support due to problems in other parts. The presentation: (links to source code and further information are in the presentation) http://www.reactos.org/media/docs/2010/arwinss.pdf With the best regards, Aleksey Bragin.
Re: comctl32: Fix bitmap size calculation
On Mar 27, 2009, at 6:47 PM, Vitaliy Margolen wrote: Anyway, e.g. Sib Icon Edit required ~ 30 Mb (something like 27 images * 13440 width * 24 height * sizeof(each pixel)) of memory for every instance to run (due to this bug). Now it requires only about 300kb Fixing one app doesn't mean it's correct. Yes, there is an obvious error in the image list, but you are not just fixing it. You also removing some functionality that tool bar depends on. I'm not fixing an app (not one, but every which uses this codepath, might be not many but in Wine you would not notice this due to different memory model than in a real OS), I'm fixing a wrong behavior when width of whole bitmap was confused with width of one item in the image list! Simple formula: NewTotalWidth = NewItemCount * WidthOfOneItem (correct one), and now in Wine: NewTotalWidth = NewItemCount * TotalWidth. Then, after fixing, cx parameter becomes unused and thus gets deleted. There was no way of changing individual image list item's width with that cx parameter. The only possibility of its usage might have been checking if image list is going to be reduced instead of expanded, but that check is there, and is performed without using cx. Am I wrong?
Re: comctl32: Fix bitmap size calculation
On Mar 27, 2009, at 3:39 AM, Vitaliy Margolen wrote: Aleksey Bragin wrote: Fix bitmap size calculation in IMAGELIST_InternalExpandBitmaps and remove unneded parameter. Memory requirements are greatly reduced after this fix. The bug was an ambiguous meaning of a cx parameter, which was supposed to be a width of an individual image inside the list, but width of a whole bitmap was passed in thus making memory requirements huge (number of images * width of whole bitmap = required bitmap size). Furthermore, cx parameter is redundant because all checks are already there (that the image list can't be reduced), and besides of that there is no use for it anymore. Thus it's been removed. That bug was introduced while attempting to change the size of the bitmaps for the toolbar. Looking at the code it's rely iffy if image list really should be able to do that at all. Or that toolbar should handle the resize itself (most likely). The commit I'm talking about is: commit 19cef6ca1059140d00ac8b445ab3f9eb0491f239 Author: Gerard Patel Date: Sat Jul 8 12:48:37 2000 + Allow the size of bitmaps to be changed after toolbar buttons have been added. With your patch you "disable" this ability (which I don't think is working anyway). So some tests are in order. At least a test program demonstrating what's the correct behavior. Vitaliy Yes exactly, however I didn't provide any testcase, because I just removed non-used parameter and fixed existing code. If someone wants to implement image list having variable width of each image - he's free to proof that Windows does this (which I very much doubt). Anyway, e.g. Sib Icon Edit required ~ 30 Mb (something like 27 images * 13440 width * 24 height * sizeof(each pixel)) of memory for every instance to run (due to this bug). Now it requires only about 300kb :-).
