Hi all
Do we really need the binary download anymore? The binary is highly
downloaded, but I suspect that those that do download it then proceed
to the iso/livecd/bochs/qemu downloads which are more usable (if they
aren't too frustrated at that point).
Should we remove it? Does anyone object to that?
Cheers
Jason
Hi guys:
May I suggest something? I believe that the current code flow ros-wine is something like this
Let's hope this ASCII drawing won't break on the way
ROS developers WINE developers
| |
| |
v v
ROS Code <--- merges ---> WINE Code
^
|
---- Here seems that things won't merge quite well
sometimes that takes considerable work
and also a source of lost work.
So what about this? I beleive it will be better for everybody in the long run.
ROS developers ------- (ROS + WINE changes) -----><--------------- WINE developers
| |
| (ROS only changes) |
v v
ROS code in <--- Automatic Mirroring (scripts?)---- WINE code in cvs server
(subversion?) of common code
I bet WINE people will be happy with this without doubt (thing won't change too much for them)
I guess there will be some friction at the beginning here(maybe) because now ROS developers have to use both systems
also ROS code implementing things not present or better than the one in wine will need to be merged into WINE but the good part is that is only once. Also ROS needs to be changed to be able to receive WINE code without changes but again this is only once and also does not needs to be done for all dlls/applications at once. I suggest to do this in small scale to see how it works. Well guys you all know more about this than me so I guess you could improve this.
Regards
Waldo Alvarez
________________________________
From: ros-dev-bounces(a)reactos.com on behalf of Alex Ionescu
Sent: Tue 12/21/2004 1:41 PM
To: ReactOS Development List
Subject: Re: [ros-dev] more sharing with Wine?
Gunnar Dalsnes wrote:
> Hi,
>
> I'm tired of fixing bugs in code ported from wine <x> years ago. In
> most cases the bugs has already been fixed in the wine code we ripped
> from, but the ros variant is forked so much its impossible to inc.
> those fixes into ros, so the only choice is to rip the whole wine
> source over again, loosing any possible fixes/improvements we had made
> to the ros variant vs. the wine variant.
>
> Take for example the file lib\kernel32\misc\profile.c. This file is
> 99.9% unchanged from wine, and only includes and some prototypes
> needed changes. I want to move files like this into wine subdirs. like
> lib\kernel32\misc\wine\profile.c and generate an initial diff
> lib\kernel32\misc\wine\profile.diff with changes made to make it run
> on ros using the wine porting headers. It does not mean that this diff
> will contain ERR changed to DPRINT etc. Only the bare changes to make
> it compile. Moving files into wine dirs in off course not necesary,
> but it makes it clear that this file(s) are shared thus there are
> rules to follow when changing them.
>
> I have made scripts that updates our profile.c, using the profile.diff
> and any updated profile.c from wine, and i have made a script for
> generating patches that we send to wine. It all seems to work fine.
> HELP: where does the winehq2ros.patch files used in comctl32 etc. fit
> into this?
>
> The only problem is wines strange unicode strings, their FIXME, ERR
> etc. and indentation. I think its worth it if we can share more, but
> dunno if the majority agrees.
>
> From what i can see, much of kernel32 and ntdll can be shared this
> way, and probably much stuff in user32/gdi32 also.
>
> Regards
> Gunnar
Personally, what bugs me is that if Wine fixes something, it's our
responsability to merge it and cope with it. If we fix something, it's
still our responsability. This latter statement bugs me. Of course it's
up to us to implement Wine's changes, but why should we be the ones that
also send our pathces back to wine, and have them all formatted back
into Wine mode. It seems unfair to me that they don't submit their bug
fixes to us, and it's up to us to sync and make them proper, while it's
ALSO up to us to wineize our patches and send them to Wine.
Anyways, whatever tool/script makes importing Wine's code into ROS and
making it look nice is 100% OK with me.
Best regards,
Alex Ionescu
_______________________________________________
Ros-dev mailing list
Ros-dev(a)reactos.com
http://reactos.com:8080/mailman/listinfo/ros-dev
Hi Martin:
Last time I saw it no I haven't checked in a while), but I guess my answer should be not yet since I have not seen any discussion about that on the list until now that you ask. If you want to be sure check ntdll (the interface is machine generated so you need to check the program that builds it, what I remember is that it generated an .asm, you can also check the asm after you build the system). Also the ROS build system needs sub architectures configurable to use this one since this instruction is PII+ hey I bet we all know we are missing a lot of great stuff only implemented in more recent processors, SYSCALL is only one of them. Another thing that could be done is to detect the CPU at some time during initialization and use one of two ntdll (on with SYSCALL an another without it). The question is: should an installed ReactOS resist a CPU downgrade? Probably yes but most of the times is just a waste.
regards
Waldo
________________________________
From: ros-dev-bounces(a)reactos.com on behalf of Maritn "E.T." Misuth
Sent: Wed 12/22/2004 5:10 PM
To: ReactOS Development List
Subject: [ros-dev] SYSCALL instruction
Does ReactOS use optimized SYSCALL instruction on modern processors when
invoking kernel functions?
_______________________________________________
Ros-dev mailing list
Ros-dev(a)reactos.com
http://reactos.com:8080/mailman/listinfo/ros-dev
This patch works around the 'hanging after 2nd stage install' bug but I
don't really understand what's going on here. Basically, It looks like
ProcessData is null on the very last call (the one that would seemingly
flush the registry and reboot).
If i comment the break, nothing breaks and reactos reboots as expected
when i press the reboot button.
--
Here's a simple experiment. Stand on a train track between two locomotives
which are pushing on you with equal force in opposite directions. You will
exhibit no net motion. None the less, you may soon begin to notice that
something important is happening.
-- Robert Stirniman
Hi,
I'm tired of fixing bugs in code ported from wine <x> years ago. In most
cases the bugs has already been fixed in the wine code we ripped from,
but the ros variant is forked so much its impossible to inc. those fixes
into ros, so the only choice is to rip the whole wine source over again,
loosing any possible fixes/improvements we had made to the ros variant
vs. the wine variant.
Take for example the file lib\kernel32\misc\profile.c. This file is
99.9% unchanged from wine, and only includes and some prototypes needed
changes. I want to move files like this into wine subdirs. like
lib\kernel32\misc\wine\profile.c and generate an initial diff
lib\kernel32\misc\wine\profile.diff with changes made to make it run on
ros using the wine porting headers. It does not mean that this diff will
contain ERR changed to DPRINT etc. Only the bare changes to make it
compile. Moving files into wine dirs in off course not necesary, but it
makes it clear that this file(s) are shared thus there are rules to
follow when changing them.
I have made scripts that updates our profile.c, using the profile.diff
and any updated profile.c from wine, and i have made a script for
generating patches that we send to wine. It all seems to work fine.
HELP: where does the winehq2ros.patch files used in comctl32 etc. fit
into this?
The only problem is wines strange unicode strings, their FIXME, ERR etc.
and indentation. I think its worth it if we can share more, but dunno if
the majority agrees.
From what i can see, much of kernel32 and ntdll can be shared this way,
and probably much stuff in user32/gdi32 also.
Regards
Gunnar
royce(a)cvs.reactos.com wrote:
>CVSROOT: /CVS/ReactOS
>Module name: reactos
>Repository: reactos/ntoskrnl/mm/
>Changes by: royce(a)mok.osexperts.com 04/12/21 21:17:46
>
>Modified files:
> reactos/ntoskrnl/include/internal/: test.h
> reactos/ntoskrnl/ke/i386/: exp.c
> reactos/ntoskrnl/mm/: virtual.c
>
>Log message:
> MiQueryVirtualMemory(): created because ZwQueryVirtualMemory() didn't work for me, added cases for memory area types that I needed to walk stack traces.
> Stack traces now use MiQueryVirtualMemory to make sure they never step outside the allocated stack they started in ( this prevents page faults at high irql ) - for some reason this patch eliminates the NtW32Callback() crash everybody is seeing with GDI_DEBUG enabled, tho I don't understand why.
>
>
>
>
Nice fix Royce.
Keep it up!
Best regards,
Alex Ionescu
Hello,
I got :
Current date: 2004-12-20
ROS Version : 0.3-CVS (Build 20041220)
rcopy.c: In function `copy_file':
rcopy.c:90: error: storage size of `ut_buffer' isn't known
rcopy.c:132: warning: implicit declaration of function `utime'
rcopy.c:90: warning: unused variable `ut_buffer'
make[1]: *** [rcopy] Error 1
make: *** [tools] Error 2
Regards, David
After reading a question on the forum, I decided to find out exactly what is
keeping Visual Basic programs from running and see if it's easy to fix. It
turns out that about the first thing that the VB runtime (msvbvm60.dll) does
is check the version number of the OS. At the moment we return:
dwMajorVersion = 4
dwMinorVersion = 0
dwBuildNumber = 0
dwPlatformId = 2
szCSDVersion = "ReactOS 0.2.5-CVS (Build 20041216)"
wServicePackMajor = 6
wServicePackMinor = 0
wSuiteMask = 0
wProductType = 0
The VB runtime wants at least NT4/SP3. The checks that currently fail are
dwBuildNumber (needs at least 1381) and the check for the service pack. It
expects the szCSDVersion field to be "Service Pack x" and extracts the
service pack number from that. (Good thing btw that there are not more than
10 service packs for NT4...).
Anyway, dwBuildNumber will have to be increased to 1381, that's no problem.
But the szCSDVersion is currently the only way for usermode programs to get
the ReactOS version. I know it's used by e.g. cmd.exe to display the version
number.
So, I don't think we have much choice, szCSDVersion will have to be set to
"Service Pack 6". Question is how to make the ReactOS version string
available. I've been thinking about adding it after the "Service Pack 6"
string (so the sp6 string is terminated with a nul byte, following the nul
byte is the ReactOS version string). Another option would be to store it in
the registry, but that would mean that it could get out of sync with the
version info in the kernel.
So, I'd like to store it as second string in szCSDVersion. Any objections to
that?
Gé van Geldorp.
