HI
I am been rethinking over some thing in ReactOS
mean while I will not be avail coding on ReactOS at all
or do any commit or helping people as I use to.
I am still piss over some matter betwin me and Alesky
this matter is betwin us two. What happen betwin us
is betwin us. That is all I have say for now. about
that matter.
And I am rethinking over a sugestions I got from a old
freind maybe start working for him. I do not known
if I do i can not be coding on any opensource project
the contract is for long terms contract and will need
all skill I have. I got this offer for long time ago
and I did say no to it, but it still stand,
reason I did say no to it was I did not want coding behine dorrs or
come up new ideas that being use behine dorrs and u are not avail
to talk about them. I see allot of my life works are being using of
all people that own a laptop or cellphone today.
But one can backtrace the techlogic to me. what I done.
That is how I did want thing be when I was younger.
it is some background info what I did before 2003
after I join ReactOS most people I known ask me if I can quit
from ReactOS and start working for them. One video card manufactor
did contact me when I join ReactOS I can not tell which one.
I solv the main issue I and the manufactor did have.
it was how to open directx hal for the graphic card.
next issue I solv was how to create a surface and access all other
part of directx hal. Next issue we got was DirectX DdBlt it did not
work direcly it took me and the manufactor around 2 days figout
how to use DdBlt so it was avail to blit and see it on the screen.
This informations did not exstis at all in MSDN. after I told open
how it was done and start implemeted it in reactos MS did update the
doc how to optain DirectX HAL. See GdiEntry1-16
This does not mean I am leving ReactOS
it mean I need rethink what I want todo
the options I got is very good one. I like
the offer I got. and I do not known if I will say yes or no
I am not a person say direcly no to money but none can buy me
for money. I choice what I want todo. even it is bad payment.
I have say no to many good deal and work in pass.
Steven
what I told u before, I stand with my word, and waiting on
you mail about the details.
To reash me is not via irc any longer
it is on icq / skype or my mail address.
Bestregards
Magnus Olsen
Hi,
this question seems to arise periodically, so let's have a
constructive discussion again about the issue once again.
The issue is being that a lot of people have direct commit access to
the repository, and sooner or later some of them commit patches which
introduce a regress in functionality.
I will use Magnus (GreatLord) again as an example. He was doing a
good thing (as usual), but then somehow lost focus, and along with
good fixes committed a breakage for FF2.0 installer (and all other
apps using PatBlt functions). I had to (as usual!) spend the whole
morning reviewing all his diffs, then regress-testing by bisection to
find the guilty revision, then work out a better solution with him,
and then come to agreement that the guilty commit could be just
reverted for now, since it partly works anyway.
This takes up significant amount of my time, which could go into
something more productive than just testing patches, finding way to
unregress, and so on.
Especially I'm angry about this happening right when approaching
0.3.5 release.
Ideally (as I explained in #reactos today to blight_), I want the
trunk itself be directly committable only by a very limited number of
persons, and all developers should be committing to "some other
place" at first, and then their patches merged by reviewers/testers
(yes, manually, sometimes just reviewing may be enough to commit/
reject the patch, sometimes a thorough testing must be involved,
maybe additional devs asked for a review).
blight_ called this as a "linux development model" with an
intermediate branch - yes, maybe, why not?.
What I definately don't want to do is to scare developers away and
make their life more complicated by need of sending text patches
(this is just not convinient, and as seen on the example of Wine
makes a lot of possible contributors going away).
I remember what Alex proposed (those who don't, may look up ros-dev
ML archives with a similar topic).
Would there be any new prepositions? Maybe someone discovered a new
CIS for SVN, or a decentralized VCS for patch submission and usual
SVN for maintaining HEAD?
With time, developers number is only going to increase, so this
problem will become more and more annoying.
With the best regards,
Aleksey Bragin.
Hi,
I'm going to explain this ONCE:
1st: The move was to conserve and reduce space and size of the current
structure.
Writing a floating point package could be hard to do or just copyleft
one off the net.... Problem is if we do the later it will most likely
not be compatible with M$ SFPP. BTW, M$ did patent their strange and
unusual floating point package. Which means I can not write one! Just
writing the storage emulation is almost a problem too... But due to US
patent law I can just do what I did, to "Talk to the Interface" with
the storage emulation.
Keeping the current state of ReactOS FP is my first choice. We use the
speed of the FPU which is part of the main processor and reduce the
size of the source. (Two pluses so far, Speed and Small Size.) The
storage emulation for gdi32 is important for compatibility and with
ReactOS concept of drop in replacement and play.
Thanks,
my 1EU
References:
Fast floating-point truncation to integer form - US Patent 6535898:
http://v3.espacenet.com/textdoc?DB=EPODOC&IDX=US6535898&F=0
Use of indices for queries with comparisons based on a function:
http://v3.espacenet.com/textdoc?DB=EPODOC&IDX=EP1193619&F=0
System and method for fast and smooth rendering of lit, textured spheres:
http://v3.espacenet.com/textdoc?DB=EPODOC&IDX=EP1227443&F=0
John R. Hauser SoftFloat package :
http://www.jhauser.us/arithmetic/SoftFloat.html
IEEE 754 floating-point test software:
http://www.math.utah.edu/~beebe/software/ieee/
Hi,
I experience a hang of FF 1.5 installation app at "0% Extracting".
Sometimes hangs completely (even mouse doesn't move), sometimes I'm
able to click "X" and choose yes to cancel.
It started happening at least since yesterday.
WBR,
Aleksey Bragin.
Hi,
I like to start testing FF again on hardware but this bug is still open.
http://www.reactos.org/bugzilla/show_bug.cgi?id=2987
I've copied most of the netamd.inf from Ros to match with the inf for
the driver. But still the same crash.
Please let me know,
James
Hi!
There was a reason for doing what I commit'ed,,,, since you are
looking at it can you please fix this.
8^)
James
gdi32_winetest pen
ExFreePool of already freed address 80e8ba78
KeBugCheck at ntoskrnl/mm/npool.c:1566
*** Fatal System Error: 0x00000000
(0x00000000,0x00000000,0x00000000,0x00000000)
Entered debugger on embedded INT3 at 0x0008:0x808ac7d8.
kdb:> bt
Eip:
<NTOSKRNL.EXE:ac7d9 (lib/rtl/i386/debug_asm.S:42
(RtlpBreakWithStatusInstruction))>
Frames:
<NTOSKRNL.EXE:29a2 (ntoskrnl/ke/bug.c:1100 (KeBugCheckWithTf@24))>
<NTOSKRNL.EXE:2aac (ntoskrnl/ke/bug.c:1364 (KeBugCheck@4))>
<NTOSKRNL.EXE:5f00c (ntoskrnl/mm/npool.c:1567 (ExFreeNonPagedPool@4))>
<NTOSKRNL.EXE:61e64 (ntoskrnl/mm/pool.c:238 (ExFreePool@4))>
<win32k.sys:967ff (subsystems/win32/win32k/objects/pen.c:344
(NtGdiExtCreatePen@44))>
<NTOSKRNL.EXE:96eda (ntoskrnl/ke/i386/trap.s:244 (KiFastCallEntry))>
<ntdll.dll:5dda>
<gdi32_winetest.EXE:3b497>
<gdi32_winetest.EXE:3d605>
<gdi32_winetest.EXE:3d78d>
<gdi32_winetest.EXE:3dc3d>
<gdi32_winetest.EXE:3dc6a>
<kernel32.dll:21610>
<00000000>
On Tue, Jun 3, 2008 at 5:08 PM, Colin Finck <mail(a)colinfinck.de> wrote:
> The Wine test framework is currently only used by tests imported from Wine,
> so an own test suite for ws2_32.dll might get lost there.
You could have written the tests for the wine test suite and submitted them.
> Also Timo's testing framework offers some interesting features like HTML
> output not offered by the Wine one.
Sure, but given the size of the wine test suite verses Timo's I think
the effort is
better spent adding this to winetest
> Additionally, we have a free hand here and can play with it as we want,
> while we can only import and maybe make little changes to the Wine test
> framework if we want to avoid a big merging mess.
Your always free to fork. As I said given the large number of unit
tests in the Wine framework
it seems to make more sense to me to extend that rather than develop a new one.
Besides you can add the features you need to the Winetest gui and have
it be independent
of the framework as a whole.
--
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
I'm getting *quite* annoyed with seeing these kinds of tests:
ret = SomeFunc();
ASSERT(ret == success);
How exactly is this a test anyway? It proves in NO way that the
function *worked*, only that it returned success. Furthermore, there
are *plenty* of cases where a function could legitimately fail -- it
is simply stupid to assume that a failure means a regression. What if
the system is out of memory?
On Sun, Jun 1, 2008 at 10:38 PM, <greatlrd(a)svn.reactos.org> wrote:
> Author: greatlrd
> Date: Sun Jun 1 09:38:02 2008
> New Revision: 33807
>
> URL: http://svn.reactos.org/svn/reactos?rev=33807&view=rev
> Log:
> add Test for EngDeleteSemaphore, it only test if it been create or not
>
> Added:
> trunk/rostests/apitests/gdi32api/tests/EngCreateSemaphore.c (with props)
> Modified:
> trunk/rostests/apitests/gdi32api/testlist.c
>
> Modified: trunk/rostests/apitests/gdi32api/testlist.c
> URL: http://svn.reactos.org/svn/reactos/trunk/rostests/apitests/gdi32api/testlis…
> ==============================================================================
> --- trunk/rostests/apitests/gdi32api/testlist.c [iso-8859-1] (original)
> +++ trunk/rostests/apitests/gdi32api/testlist.c [iso-8859-1] Sun Jun 1 09:38:02 2008
> @@ -11,6 +11,7 @@
> #include "tests/CreateFont.c"
> #include "tests/CreatePen.c"
> #include "tests/CreateRectRgn.c"
> +#include "tests/EngCreateSemaphore.c"
> #include "tests/ExtCreatePen.c"
> #include "tests/GdiConvertBitmap.c"
> #include "tests/GdiConvertBrush.c"
> @@ -51,6 +52,7 @@
> { L"CreateCompatibleDC", Test_CreateCompatibleDC },
> { L"CreateFont", Test_CreateFont },
> { L"CreatePen", Test_CreatePen },
> + { L"EngCreateSemaphore", Test_EngCreateSemaphore },
> { L"CreateRectRgn", Test_CreateRectRgn },
> { L"ExtCreatePen", Test_ExtCreatePen },
> { L"GdiConvertBitmap", Test_GdiConvertBitmap },
>
> Added: trunk/rostests/apitests/gdi32api/tests/EngCreateSemaphore.c
> URL: http://svn.reactos.org/svn/reactos/trunk/rostests/apitests/gdi32api/tests/E…
> ==============================================================================
> --- trunk/rostests/apitests/gdi32api/tests/EngCreateSemaphore.c (added)
> +++ trunk/rostests/apitests/gdi32api/tests/EngCreateSemaphore.c [iso-8859-1] Sun Jun 1 09:38:02 2008
> @@ -1,0 +1,15 @@
> +/* Simple test of EngAcquireSemaphore only check if we got a lock or not */
> +INT
> +Test_EngCreateSemaphore(PTESTINFO pti)
> +{
> +
> + HSEMAPHORE hsem;
> + hsem = EngCreateSemaphore();
> +
> + RTEST ( hsem != NULL );
> +
> + EngDeleteSemaphore(hsem);
> +
> + return APISTATUS_NORMAL;
> +}
> +
>
> Propchange: trunk/rostests/apitests/gdi32api/tests/EngCreateSemaphore.c
> ------------------------------------------------------------------------------
> svn:eol-style = native
>
>
--
Best regards,
Alex Ionescu
Hi!
I checked this and it is all wrong,,,,, I reverted part of revision 19267:
Replacing the code with the original wine code that behaves like
"Windows code" but should be called inside EngCreateBitmap if (pvBits)
Width = DIB_GetDIBWidthBytes( lWidth, iFormat); .
As it should be:
INT FASTCALL DIB_GetDIBWidthBytes (INT width, INT depth)
{
// return ((width * depth + 31) & ~31) >> 3;
int words;
switch(depth)
{
case 1: words = (width + 31) / 32; break;
case 4: words = (width + 7) / 8; break;
case 8: words = (width + 3) / 4; break;
case 15:
case 16: words = (width + 1) / 2; break;
case 24: words = (width * 3 + 3)/4; break;
default:
DPRINT1("(%d): Unsupported depth\n", depth );
/* fall through */
case 32:
words = width;
}
return 4 * words;
}
On Sat, May 31, 2008 at 7:15 PM, <tkreuzer(a)svn.reactos.org> wrote:
> Author: tkreuzer
> Date: Sat May 31 18:15:34 2008
> New Revision: 33792
>
> URL: http://svn.reactos.org/svn/reactos?rev=33792&view=rev
> Log:
> preserve code for NtGdiCreateEnhMetaFile from win32k (where it's going to be removed later) in gdi32 (where it's going to be implemented later)
if your going to implement it all in usermode are you going to try to
just rip the Wine metafile and enhanced metefile drivers?
Thanks
--
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
I hope everyone is clear in his mind about the fact that this makes up
20 % of the complete reactos source or in other words increases the size
of the code by 25% ...
> [ros-diffs] [hyperion] 33703: added nls added nls/3rdparty added nls/3rdparty/icu We
> officially welcome IBM's excellent ICU4C library for Unicode support to
> our humble source tree. May our marriage be long, happy and fertile.
>
>
Hi,
Owner Menu Drawing if I remember right, which allows application to
draw their own menus. Yes that is right! Not all applications use MDI.
Well, it is now all broken (It was in a state of NEAR DO WELL). I
understand the reason for wine testing but please understand What You
See Is What You Get.
>From the debug output:
IntSetMenuItemInfo: Invalid combination of fMask bits used
It draws a small little box with the line separators. 8^' looks cute~
I need to stay focus on the issues I'm working on,, please help me by
fixing this new issue, please don't send me patches,
8^)
James
On Thu, May 29, 2008 at 9:27 PM, <greatlrd(a)svn.reactos.org> wrote:
> Author: greatlrd
> Date: Thu May 29 20:27:29 2008
> New Revision: 33764
>
> URL: http://svn.reactos.org/svn/reactos?rev=33764&view=rev
> Log:
> 1. do not use wine def for reactos
> 2. this is almost 100% correct list of windows 2003 export list of msvcrt.def and it will make abiword working again for it was missing api wfreopen and allot more api from msvcrt
> 3. this add back api that was remove api they exists in windows 2003 export list
> 4. List was provide from colin f
>
> See issue #3293 for more details.
I'd suggest putting a comment at the top of the def so that in the
future someone won't make this mistake again. Any idea why it works on
Wine with the missing exports but not ReactOS?
--
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
Hi,
Could it be easier to just:
static GDIDEVICE PrimarySurface;
PGDIDEVICE pPrimarySurface = &PrimarySurface;
then use pPrimarySurface through out? I will have to rewrite
everything later to support the new HDEV code.
IDEA~! Stefan100 theres a good patch! ;^D
Thanks,
James
On May 28, 2008, at 4:41 AM, tkreuzer(a)svn.reactos.org wrote:
> 1.28: Jonathan Ernst <jonathan(a)ernstfamily.ch>
> Update the address of the Free Software Foundation.
This should fix a lot of crashes, since many apps would try to
dereference FSF's address, but it would be invalid!
:-)
WBR,
Aleksey Bragin.
On Fri, May 23, 2008 at 1:55 PM, <fireball(a)svn.reactos.org> wrote:
> - msiexec is GUI app, not CUI.
Is this a Wine bug then? It has it listed as a console based
application. When you run msiexec directly on Windows I know it does
not start a console window so I guess this would imply it is a GUI
with a hidden window right?
--
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
On Tue, May 20, 2008 at 8:53 AM, <dchapyshev(a)svn.reactos.org> wrote:
> +#include "../kbswitch.h"
Could you set an include path and remove the ../ from the source?
gnumake throws a fit with parallel makes and relative paths.
--
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
If GetWindowsDirectory fails, you have much worse issues to worry
about than executable redirection.
Also note that regedt32.exe is usually in the system32 directory, so
how is this a security/redirection issue exactly?
This implies someone would have to:
1) Give you a malware regedit.exe in directory foo
2) Give you the legitimate regedt32.exe in directory foo
3) Somehow convince you to:
3.1) Use regedt32 instead of regedit (few people even know this tool)
3.2) Launch regedt32 from this "foo" directory instead of using
start/run regedt32
The issue you're looking for just doesn't exist.
2008/5/19 FENG Yu Ning <fengyuning1984(a)gmail.com>:
> On Sun, May 18, 2008 at 7:28 PM, Alex Ionescu <ionucu(a)videotron.ca> wrote:
>>
>> Last nitpick: if you can't get the windows directory, just
>> ShellExecute "regedit.exe" directly, as the code originally did --
>> this is the behavior on Windows, fyi.
>>
>
> Though it is the behavior on Windows, it is a bad thing, IMHO. There are
> already too many little viruses who pretend to be a system executable, say,
> explorer.exe, and they are placed in a (sub)directory of the windows
> directory to be shell executed. If we can't get the windows direcoty, we
> should let the user know, and give them the chance to fix it, instead of
> blindly execute anything.
> I used to suffer from those, and they were really annoying. Please consider
> being different from Windows in this and similar issues.
> MHO.
>
> _______________________________________________
> Ros-dev mailing list
> Ros-dev(a)reactos.org
> http://www.reactos.org/mailman/listinfo/ros-dev
>
>
--
Best regards,
Alex Ionescu
--
Best regards,
Alex Ionescu
Hi,
I warn you guys about the menu code, so far everything looks okay.
Fireball: "guys, dlls/win32k/user32/menu.c" "line 240" "it HeapFrees
ItemInfo->dwTypeData" "but who HEapAllocates it?!", Answer the Q.
MenuGetRosMenuItemInfo does.... Please understand I worked my ass off
back on 0.3.0? to fix the mess in user32 menu. Please Think before you
Code. Have a list of test apps to make sure it does work like YOU
think it should. Wine is not enough!.
Thanks,
James
As a ReactOS-User I thoght sometimes, which is better: ReactOS or Linux with WINE.
WINE is much more mature and can also run Windows 3.11 programs.
But ReactOS - on the other side - is more Windows-like. It is a complete Operating System like Windows. And the applications for ReactOS can also be running in binary form on Windows and are not Linux-/Unix-native applications which are additional compiled against a winelib.dll.
On the ReactOS-side stand the everyone known text
"ReactOS aims to achieve complete binary compatibility with both applications and device drivers meant for NT and XP operating systems, by using a similar architecture and providing a complete and equivalent public interface."
That is one of the differences to WINE: Being also driver-compatibe to XP.
But thats also a point, where I ask myself, how much sense this make.
Windows NT could run a lot of Windows 95/98 programs. Windows XP could run most Windows NT, Windows 9x and Windows 3.x programs. Windows Vista runs not all but some of the Windows XP and Windows NT programs.
But on the driver side, Windows XP could only some Windows NT driver (like printer-driver).
As I read for some time, for Windows Vista existing lesser driver then for Linux. So, it seems not, that Vista could use some of the plenty of Windows XP driver.
Also Vista existing as 32bit and 64bit. And the 64bit system can not use 32bit driver.
Follower of Vista (for example Windows 7) will only be existing as 64bit system.
So, you want to be driver-compatibe to Windows. But Windows will itself not be drivercompatibe to older or newer versions.
I have read anywhere in the Internet, that it is planned, that in newer Windows-versions only driver can be used and installed, which are trustable. And only Microsoft dicide, which drivers are trustable and which not. And driver-creator have ro pay on Microsoft that they make the drivers authorized/trustable.
This makes it also more senseless to be driver-compatibe to Windows.
But ReactOS have the advantage, that it looks and feels in all areas like Windows. And you can run Windows-programs on it. That is really an advantage of ReactOS.
Possible ReactOS would be anytime cooperate with DeviceVM ( the company behind SplashTop http://www.splashtop.com/index.php ) . Because it is possible, that there are people who would prefer an Windows/ReactOS system which starts fast on an RAM instead of an Linux-System.
In the new Newsletter (#41) of ReactOS stands, that Steven Edwards comes back to interact again between ReactOS and WINE.
Thats a very good news. Hopefully all the WINE-developers see ReactOS in some time as legal and use again ReactOS-code for WINE, so that ReactOS and WINE could again more cooperate.
There are still some developer (like GvG and others) who have left ReactOS and thought, that ReactOS isn't legal in USA-laws. I still think, that it is a big problem, that there are some ex-developer of ReactOS and some WINE-developer, who beliefs, that ReactOS is illegal. A more intensive dialog with this people is needed I think.
Greatings
theuserbl
_________________________________________________________________
Die aktuelle Frühjahrsmode - Preise vergleichen bei MSN Shopping
http://shopping.msn.de/category/damenbekleidung/bcatid66/forsale?text=categ…