We're now in code freeze for 0.2.5. That means that only fixes for
showstopper bugs will be allowed into the 0.2.5 branch and developers should
discuss their fixes on the mailinglist before committing.
0.2.5 RC2 is available from our SourceForge download page.
The official release for 0.2.5 will be tomorrow, just before the move to
SubVersion starts.
Gé van Geldorp.
CVS->SVN: when will freeze & convert actually happen (date/time/UTC)?
Emanuele
____________________________________________________________
Regala e regalati Libero ADSL: 3 mesi gratis e navighi veloce. 1.2 Mega di musica, film, video e sport.
Abbonati subito senza costi di attivazione su http://www.libero.it
Gang,
I wasn't paying real close attention to IRC today, but I saw that
someone said that with todays networking changes they were able to get
to the "login:" prompt of PuTTY, but were unable to type anything into
the window.
Well, I couldn't help myself, so when I got home I tried out PuTTY
with the same results. Not to be outdone by a bug, I pulled my
private key off my existing PuTTY install and loaded the key under
ros. I was able to login using auto-username and key authentication
to my linux box. Of course, I was unable to type anything into the
window, but I thought I would let everyone know that I was technically
able to establish a SSH2 connection from ReactOS to linux. ;0)
Good work!
WD
--
The cheese stands alone.
Hi all
Please read the attached message if you live in or near Russia. Is
someone willing to take the lead in manning a booth? You can even make
a speech if you like :)
Cheers
Jason
---------- Forwarded message ----------
From: "Vera Semyonova" <vera.semyonova(a)fort-ross.ru>
To: <jasonfilby(a)yahoo.com>
Date: Mon, 27 Dec 2004 17:57:49 +0300
Subject: Open Source Forum Russia
Dear Jason Filby,
Please find hereby information about the first Open Source Forum in
Russia. We will be delighted if you find an opportunity to participate
with a booth in the exhibition part or (and) attend as a speaker in
the conferecne program.
Looking forward to hear from you,
Sincerely,
Vera Semyonova
CEO
Fort-Ross
Open Source World Russia
27-29 April, 2005
Moscow, Radisson SAS Hotel
Mission statement
The Open Source World Russia is the first conference and exhibition in
Russia which will be entirely dedicated to open source software
development. The open source model has become extremely popular all
over the world, and Russia is no exception. Many major international
companies show their interest in promoting the open source solutions
in Russia. About 75% of Russian software development companies already
use the open source model for their international customers.
The mission of this conference is to boost the confidence of the
Russian IT market for open source solutions.
Audience
IT-directors, project managers, software developers, system
administrators, industrial enterprise directors, representatives of
the governmental authorities and others will be the visitors of the
exhibition and participants of the conference.
Overall number of the exhibition visitors expected: 3000+.
Overall number of the conference participants expected: 500+.
Organizers of the Conference
1.Fort-Ross, the leading marketing and event company organizing varied
conferences and trade shows in the field of IT and software in Russia,
2.Linux Ink., since 1993 the pioneer of professional support and
distribution of Linux systems in Russia.
Programme Committee
John Maddog Hall (Linux International),
Ceren Cerenov (MERT RF),
Alexei Smirnov (ALT Linux),
Vyacheslav Zvyagintsev (Linux Ink)
Valentim Makarov (RUSSOFT)
Alexander Andreev (Softjoys)
IBM
Novell
Duration of the Conference: 3 days
Plan of the Conference
1.The Opening Ceremony
Speakers:
representatives of the Russian Government,
organizers of the event,
several VIP speakers.
2.Exhibition (free for visitors):
1.Linux City: a specially decorated area where visitors can see live
demonstrations of various open source solutions that together build a
common infrastructure. Linux City will present a model of real
enterprises, small offices, communication infrastructure,
entertainment zone etc. Each node of this model might have its own
sponsor.
2.Exhibition Area
This area invites the open source projects (maintainers or their
representatives, team members) and companies to demonstrate their
state-of-the-art technologies.
3.Conference (requires registration and tickets)
1.plenary sessions, held by vendors
2.specific sections, presenting the talks
3.round-table discussions, moderated
Conference Sections and Round-Tables
1.Open Source Community (code: OSCom)
Topics for discussion:
1.project management in the Open Source software development
2.training for Open Source software development
2.Open Source Security (code: OSSec)
Topics for discussion:
1.security of software products and technologies based on the open source model
2.implementing national security standards in open source solutions
3.Open Source to e-Government (code: OS2eG)
Topics for discussion:
1.open source solutions for governmental agencies
2.communication and docflow standards
3.e-Government portals
4.Open Source to Business (code: OS2B)
Topics for discussion:
1.open source solutions for the corporate market
2.particular features of the open source business model
3.commercial support of open source solutions
5.Open Source in Education (code: OS2Ed)
Topics for discussion:
1.open source solutions for education
2.training resources and applications
3.learning process management
6.Open Source Legal Issues (code: OSLegal)
Topics for discussion:
1.open source licenses
2.intellectual property rights, copyright/copyleft, patents
Agenda
24 April 2005 (Wednesday)
13.00 – registration of participants
15.00 – grand opening of the exhibition
16.00 – beginning of the conference.
Plenary session with participation of the keynote speakers:
- representatives of the RF government at minister level,
- managers of leading international open source organizations
and companies
- Linux International, Open Source Development League, Red Hat, MySQL
- general sponsors of the Conference
19.00 – Gala reception for the VIP guests (by individual invitations)
28 April 2005 (Thursday)
9.00 - the exhibition opens
10.00 – parallel sections (OSCom, OS2eG, OS2B)
11.00 – coffee-break
12.00 – parallel sections (OSCom, OS2eG, OS2B)
13.30 – lunch for conference participants
15.00 - parallel round tables (OSCom, OS2eG, OS2B )
16.30 – coffee-break
18.00 – Reception for conference participants
April 29, 2005 (Friday)
9.00 - the exhibition opens
10.00 – parallel sections (OSEd, OSSec, OSLegal)
11.30 – coffee-break
12.00 – parallel sections and round-tables continue (OSEd, OSSec, OSLegal)
13.30 – lunch for conference participants
15.00 – round-tables (OSEd,
OSSec, OSLegal)
17.0– Official closing of the conference, summary.
Keynote speakers give closing speeches.
Practical Information
Conference Location
The conference and exhibition are to be held in the "Radisson SAS
Hotel". This is almost the only hotel in Moscow with a big
conference-hall and sufficient space for the exhibition.
The following areas of the Hotel will be used:
1.foyer of the Hotel main hall (as Hospitality Desk and as area for
the main sponsors' stands)
2.big cinema hall (up to 500 people) - for Official Opening and
Plenary session.
3.Group of "Composer halls" - for exhibition and negotiations, for
Linux City (total space is 1100 sq. m.).
4.Group of "Writers' hall" - for sections and round-tables (two halls
for 100 and 500 people)
Lunches and dinners for the conference participants will be served in
the restaurants on the first floor.
Exhibition
The total number of available stands is about 50. Among participants
of the exhibition there are Sponsors, software development companies
and system integrators.
Additional features in order to make Conference participation more effective
Besides the conference and the exhibition we are planning the
following additional features, which are intended to attract more
participants and add novelty to the event:
1.Registration for the exhibition will be done on-line, each
participant will be able to print a badge in advance by Internet, in
order not to waste time at the registration. Participants of the
conference and of the exhibition will have badges of different colors.
Number of stands to visit is checked by bar code on a badge.
2.Wireless Internet and Internet-cafe will be organized in the exhibition area
3.Linux City: live demonstration of the open source solutions can be
tested by any visitor
4.Demonstration of technologies and products based on Open Source
software will be arranged in the exhibition area.
Press coverage
The press is invited to participate in this event for free, but
preliminary accreditation is required.
Wide advertising campaign in business and computer mass media, as well
as invitation of leading periodical media as informational sponsors,
will be organized in advance.
All leading Russian IT and business newspapers and magazines will be
involved into information sponsorship and partnership with the show.
The number of mass media representatives visiting the conference will
be about 100.
Updated with CVS last night an just now.. still doesn’t compile.
I did a make clean then make
I got some errors which someone on the irc channel said were maybe because
the person forgot to commit a file in a completely different dir to CVS.
Relevant part of log is below, this is near the start where it’s going
through all the [DEPENDS] which I don’t remember last time I built it:
../../dk/w32/lib/libepsapi.a was successfully built.
wine_uuid: [DEPENDS] .uuid.d
wine_uuid: [CC] uuid.c
In file included from ../../w32api/include/windows.h:80,
from ../../include/windows.h:37,
from ../../w32api/include/rpc.h:2,
from ../../w32api/include/objbase.h:3,
from ../../include/wine/objbase.h:27,
from uuid.c:36:
../../include/wine/mmsystem.h:44: error: syntax error before "hDriver"
In file included from uuid.c:59:
../../w32api/include/vfw.h:527: error: syntax error before "FOURCC"{standard
inp
ut}: Assembler messages:
{standard input}:18: Warning: Ignoring changed section attributes for .text
../../w32api/include/vfw.h:541: error: syntax error before '}' token
../../w32api/include/vfw.h: In function `ICGetDefaultQuality':
../../w32api/include/vfw.h:968: error: `DRV_USER' undeclared (first use in
this
function)
../../w32api/include/vfw.h:968: error: (Each undeclared identifier is
reported o
nly once
../../w32api/include/vfw.h:968: error: for each function it appears in.)
../../w32api/include/vfw.h: In function `ICGetDefaultKeyFrameRate':
../../w32api/include/vfw.h:975: error: `DRV_USER' undeclared (first use in
this
function)
../../w32api/include/vfw.h: In function `ICDrawSuggestFormat':
../../w32api/include/vfw.h:989: error: `DRV_USER' undeclared (first use in
this
function)
../../w32api/include/vfw.h: In function `ICSetStatusProc':
../../w32api/include/vfw.h:998: error: `DRV_USER' undeclared (first use in
this
function)
../../w32api/include/vfw.h: In function `ICDecompressEx':
../../w32api/include/vfw.h:1017: error: `DRV_USER' undeclared (first use in
this
function)
../../w32api/include/vfw.h: In function `ICDecompressExBegin':
../../w32api/include/vfw.h:1036: error: `DRV_USER' undeclared (first use in
this
function)
../../w32api/include/vfw.h: In function `ICDecompressExQuery':
../../w32api/include/vfw.h:1055: error: `DRV_USER' undeclared (first use in
this
function)
make[1]: *** [uuid.o] Error 1
make: *** [uuid] Error 2
Any ideas? I’m stumpted.. who was working on this stuff?
---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.808 / Virus Database: 550 - Release Date: 12/8/2004
Hi Filip:
Yes that could work better so we have a single DLL and that does not consume RAM anyway ReactOS would be ready for a CPU downgrade too. btw I built some cvs snapshot today and saw the OARCH flag in the configuration file, the cpls being worked out mesa building (usable?), some text strings not in source code anymore. It failed at some point compiling explorer and I really needed to leave home but i'll keep playing with it for a while (not too much am on final exams almost)
Regards
Waldo
________________________________
From: ros-dev-bounces(a)reactos.com on behalf of Filip Navara
Sent: Thu 12/23/2004 12:37 PM
To: ReactOS Development List
Subject: Re: [ros-dev] SYSCALL instruction
Waldo Alvarez Cañizares wrote:
>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).
>
It's implemented in WinXP much easier than that. On startup it's
detected if the processor supports SYSCALL and the appropriate code is
sticked into the user shared page. The user mode code then just does jmp
at the place in user shared page and it uses the correct code. Easy ;-)
- Filip
_______________________________________________
Ros-dev mailing list
Ros-dev(a)reactos.com
http://reactos.com:8080/mailman/listinfo/ros-dev
Hello.
I have problems on linux with missing _mingw.h with both gcc-3.4.1 and
3.4.2.
It is probably caused by the last cvs commit to
reactos/include/msvcrt/string.h file.
There is mingw32/include/_mingw.h in the cross compiler directory.
Thanks, David
ROS Version : 0.3-CVS (Build 20041226)
ar: creating zlib.host.a
In file included from ../../include/tchar.h:41,
from ../../include/tgetopt.h:4,
from ../../include/getopt.h:1,
from /usr/include/unistd.h:783,
from ../../include/wine/port.h:44,
from import.c:23:
../../include/msvcrt/string.h:42:20: _mingw.h: není souborem ani adresářem
make[2]: *** [import.o] Error 1
I am testing the PCTV Rave from Pinnaclesystem .
Hivesys.inf was setup accordingly and the Pctvrave drivers installed
(bt848.sys,stream.sys,ks.sys)
The drivers of this Tuner TV card starts to load but fails to initialize
as per Debug messages below
The driver is from http://btwincap.sourceforge.net/
Please anybody have a look ?
Thanks
Gerard
--------------------------------------------------------------------
DriverBase for \SystemRoot\system32\drivers\bt848.sys: dce37000
DriverBase for \SystemRoot\system32\drivers\STREAM.SYS: dcea8000
DriverBase for \SystemRoot\system32\drivers\ks.sys: dcedc000
(ldr/loader.c:1476) LdrPEGetExportByName(): failed to find
ExSemaphoreObjectType
(ldr/loader.c:1561) Failed to import ExSemaphoreObjectType from ntoskrnl.exe
(ldr/loader.c:373) Could not process module
(ldr/loader.c:319) Could not open module file: \SystemRoot\system32\ks.sys
(ldr/loader.c:1323) Unknown import module: ks.sys (Status c0000034)
(ldr/loader.c:373) Could not process module
(ldr/loader.c:319) Could not open module file:
\SystemRoot\system32\STREAM.SYS
(ldr/loader.c:1323) Unknown import module: STREAM.SYS (Status c0000034)
(ldr/loader.c:373) Could not process module
(io/pnpmgr.c:1518) Initialization of service pctvrave failed (Status
c0000034)
(io/pnpmgr.c:1452) IopActionInitChildServices(ccc227e8, ccc40ef8, 0)
DriverBase for \SystemRoot\system32\drivers\bt848.sys: dcefd000
DriverBase for \SystemRoot\system32\drivers\STREAM.SYS: dcf59000
DriverBase for \SystemRoot\system32\drivers\ks.sys: dcf66000
(ldr/loader.c:1476) LdrPEGetExportByName(): failed to find
ExSemaphoreObjectType
(ldr/loader.c:1561) Failed to import ExSemaphoreObjectType from ntoskrnl.exe
(ldr/loader.c:373) Could not process module
(ldr/loader.c:319) Could not open module file: \SystemRoot\system32\ks.sys
(ldr/loader.c:1323) Unknown import module: ks.sys (Status c0000034)
(ldr/loader.c:373) Could not process module
(ldr/loader.c:319) Could not open module file:
\SystemRoot\system32\STREAM.SYS
(ldr/loader.c:1323) Unknown import module: STREAM.SYS (Status c0000034)
(ldr/loader.c:373) Could not process module
(io/pnpmgr.c:1518) Initialization of service pctvrave failed (Status
c0000034)
(io/pnpmgr.c:1452) IopActionInitChildServices(ccc22910, ccc40ef8, 0)
(io/pnpmgr.c:1523) Service <NULL> is disabled or already initialized
(io/pnpmgr.c:1452) IopActionInitChildServices(ccc22a38, ccc40ef8, 0)
(io/pnpmgr.c:1523) Service <NULL> is disabled or already initialized
(io/pnpmgr.c:1452) IopActionInitChildServices(ccc22b60, ccc40ef8, 0)
(io/pnpmgr.c:1523) Service <NULL> is disabled or already initialized
(io/pnpmgr.c:1452) IopActionInitChildServices(ccc22c88, ccc40ef8, 0)
On occasions I have grabbed the latest binaries and replaced the ReactOS
folder.
It always works for me and seems to be a very quick and easy way of updating
ROS without the need for burning a CD everytime.
I would say the binaries are very useful
Gedi
-----Original Message-----
From: Jason Filby [mailto:jason.filby@gmail.com]
Sent: 23 December 2004 20:07
To: ReactOS Development List
Subject: [ros-dev] Binary download
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
_______________________________________________
Ros-dev mailing list
Ros-dev(a)reactos.com
http://reactos.com:8080/mailman/listinfo/ros-dev
************************************************************************
The information contained in this message or any of its
attachments is confidential and is intended for the exclusive
use of the addressee. The information may also be legally
privileged. The views expressed may not be company policy,
but the personal views of the originator. If you are not the
addressee, any disclosure, reproduction, distribution or other
dissemination or use of this communication is strictly prohibited.
If you have received this message in error, please contact
postmaster(a)exideuk.co.uk
<mailto:postmaster@exideuk.co.uk> and then delete this message.
Exide Technologies is an industrial and transportation battery
producer and recycler with operations in 89 countries.
Further information can be found at www.exide.com
-----Original Message-----
From: Casper Hornstrup [mailto:chorns@users.sourceforge.net]
Sent: 24 December 2004 11:13
To: 'ReactOS Development List'
Subject: RE: [ros-dev] Binary download
> It was to be dropped for releases only, not daily builds. The
> registry is more likely to change from release to release than
> from day to day. If you are living on the edge and are using the
> daily builds then you are on your own and need to handle the
> errors that can occur from overwriting the installation with
> the binaries (eg. by making a clean install).
Hi Casper.
For some reason I assumed we were talking about the binaries on your site.
If your only talking about dropping the binaries on major releases via
sourceforge, then I don't see this causing a problem.
Gedi.
************************************************************************
The information contained in this message or any of its
attachments is confidential and is intended for the exclusive
use of the addressee. The information may also be legally
privileged. The views expressed may not be company policy,
but the personal views of the originator. If you are not the
addressee, any disclosure, reproduction, distribution or other
dissemination or use of this communication is strictly prohibited.
If you have received this message in error, please contact
postmaster(a)exideuk.co.uk
<mailto:postmaster@exideuk.co.uk> and then delete this message.
Exide Technologies is an industrial and transportation battery
producer and recycler with operations in 89 countries.
Further information can be found at www.exide.com
Unless it will fix a bug this shouldn't go to the release branch.
PS. We should write some rules in wiki about preparing for releases.
I can make a draft version unless someone else already beat me to it.
Casper
> -----Original Message-----
> From: ros-cvs-bounces(a)reactos.com
> [mailto:ros-cvs-bounces@reactos.com] On Behalf Of
> royce(a)cvs.reactos.com
> Sent: 23. december 2004 22:01
> To: ros-cvs(a)reactos.com
> Subject: [ros-cvs] CVS Update: reactos
>
> CVSROOT: /CVS/ReactOS
> Module name: reactos
> Repository: reactos/subsys/win32k/eng/
> Changes by: royce(a)mok.osexperts.com 04/12/23 22:01:13
>
> Modified files:
> reactos/subsys/win32k/eng/: Tag: ros-branch-0_2_5 gradient.c
>
> Log message:
> IntEngGradientFill() fix ASSERT statements
>
> _______________________________________________
> Ros-cvs mailing list
> Ros-cvs(a)reactos.com
> http://reactos.com/mailman/listinfo/ros-cvs
>
-----Original Message-----
From: Jason Filby [mailto:jason.filby@gmail.com]
Sent: 24 December 2004 10:06
To: ReactOS Development List
Subject: Re: [ros-dev] Binary download
> Sounds good; but what about registry entries that have been created by
> applications; would such an update wipe the registry or just add new
> entries and modify system entries?
That's a good point. I suppose for that to work, it would need someone to
write an update script every day to patch the existing system. That doesn't
seem viable. It takes M$ a month to do theirs, lol.
What would be the best way of updating an existing system without the need
to a complete reinstall from a CD. Burning a CD everyday to get the latest
binaries would become tedious and expensive.
Ged.
************************************************************************
The information contained in this message or any of its
attachments is confidential and is intended for the exclusive
use of the addressee. The information may also be legally
privileged. The views expressed may not be company policy,
but the personal views of the originator. If you are not the
addressee, any disclosure, reproduction, distribution or other
dissemination or use of this communication is strictly prohibited.
If you have received this message in error, please contact
postmaster(a)exideuk.co.uk
<mailto:postmaster@exideuk.co.uk> and then delete this message.
Exide Technologies is an industrial and transportation battery
producer and recycler with operations in 89 countries.
Further information can be found at www.exide.com
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.
It will be faxed to you in 30.
--- Debbie_Camerato(a)idg.com wrote:
> Right now I have only have 2 spaces left....and it is first come, first
> served, so I would send in your contract asap!
__________________________________
Do you Yahoo!?
Send a seasonal email greeting and help others. Do good.
http://celebrity.mail.yahoo.com
