The LINK : http://users.pandora.be/lieven.de.cock/CodeBlocks/CB_ansi_rev1667.7zHmm... I have a bad feeling downloading from a server with that name... :lol:
1) yesI got identical results, also on Win98SE.
2) done
3) I did this, but there were some errors.
...
4) the settings were at user key
5) and 6) files don't open in cb.
Hope that helps.
In Windows NT 4.0 and earlier, HKEY_CLASSES_ROOT displayed the data only in HKEY_LOCAL_MACHINE\SOFTWARE\Classes. The current, merged configuration lets the system independently register program classes for each user. This feature is known as per-user class registration.
if (Version.Major == 5) and (Version.Minor == 0) {
isWin2k = true;
}
Below you can find a link to an ansi build which should run on all win platforms.Are there any plans to make any more SVN builds for ANSI/Win98, or at least to have a .cbp file that can be used for such a build, given that you've put in the work to make the code compatible with Win98?
More specifially on win9x/Me. The build is based on rev 1667 with a registry patch applied (see other place in this forum for more info).
@echo off
REM This batch requieres the following Windows free software:
REM * A Code::Blocks capable of building latest SVN HEAD
REM * TortoiseSVN
REM * 7-zip
setlocal
set CB_HEAD_PATH=D:\Develop\src\codeblocks-head\codeblocks-svn
set SEVENZIP_PATH=C:\Archivos de programa\7-Zip
set TORTOISESVN_PATH=C:\Archivos de programa\TortoiseSVN\bin
set CURRENT_PATH=%CD%
echo Checking the latest revision before updating...
echo $WCREV$ > rev-before-update.log
"%TORTOISESVN_PATH%\SubWCRev.exe" "%CB_HEAD_PATH%" "%CURRENT_PATH%\rev-before-update.log" "%CURRENT_PATH%\rev-before-update.log"
if not errorlevel 0 goto FAILED
echo Running svn update...
"%TORTOISESVN_PATH%\TortoiseProc.exe" /command:update /path:"%CB_HEAD_PATH%" /notempfile /closeonend:1
if not errorlevel 0 goto FAILED
echo Checking the latest revision after updating...
echo $WCREV$ > rev-after-update.log
"%TORTOISESVN_PATH%\SubWCRev.exe" "%CB_HEAD_PATH%" "%CURRENT_PATH%\rev-after-update.log" "%CURRENT_PATH%\rev-after-update.log"
if not errorlevel 0 goto FAILED
echo Compiling Code::Blocks itself...
"%CB_HEAD_PATH%\src\output\codeblocks.exe" --build "%CB_HEAD_PATH%\src\CodeBlocks-NewBuild.cbp" > "%CURRENT_PATH%\build.log"
echo FIXME codeblocks errorlevel: %errorlevel%
echo Running update script...
cd "%CB_HEAD_PATH%\src"
call "%CB_HEAD_PATH%\src\update.bat"
if not errorlevel 0 goto FAILED
echo Compressing with 7-zip...
"%SEVENZIP_PATH%\7z.exe" a "%CURRENT_PATH%\codeblocks-svnbuild.7z" "%CB_HEAD_PATH%\src\output\*" -r -mx9 -sfx[7zC.sfx]
if not errorlevel 0 goto FAILED
echo The build has completed.
goto END
:FAILED
echo The build has failed.
:END
Hello,
version 0.5 of libunicows, a compiler-independent open source
implementation of MSLU import library, was released and is available
for download from http://libunicows.sourceforge.net. Precompiled
binaries for Visual C++ and Mingw32 are included (help with other
compilers is wanted).
MSLU (The Microsoft Layer for Unicode on Windows 95/98/ME Systems) is
a compatibility layer that makes it possible to run Unicode
applications on Windows 9x systems (previously, Unicode APIs were
only available on Windows NT/2000; see
http://www.microsoft.com/globaldev/Articles/mslu_announce.asp for
details). Necessary runtime DLLs can be downloaded from
http://www.microsoft.com/downloads/release.asp?releaseid=30039
MSLU requires that you use a special statically-linked import library
that is currently only provided for Microsoft Visual C++ and only as
a part of the (rather large) new Platform SDK. Libunicows addresses
both of these problems by being small and available in source code
form.
wxWindows 2.3 contains MSLU support and works with libunicows (VC++
makefile and configure-generated makefile for Mingw32 can both use
it). Libunicows is used in two wxWindows projects: poEdit
(http://poedit.sf.net) and Unicode build of wxPython
(http://wxpython.org).
Best regards,
Vaclav Slavik
Well, first make an Unicode build linked with unicows, so a few users of Win9x can test it. :)I just tried this for myself, building from the latest SVN (1804), and it was kind of a disaster. I built wxWidgets the usual way, with the exception that I enabled MSLU support, and linked CB against it. When I ran the program, it did load up properly (though for some reason, I had to specify the program's own directory using the --prefix option for this to work). But the program I got was very crippled. For one thing, I cannot see the editor. It just doesn't appear when I open a file, even though the title bar and the status bar both indicate an open file. Additionally, dragging a dockable pane invariably results in an immediate crash. A stack trace always reveals Opencow.dll at the end of the trace, or Unicows.dll if I use the Microsoft implementation, though I have no idea if this means MSLU is at fault.
Be sure to check that your setup.h haves wxUSE_UNICODE_MSLU = 1.
But the program I got was very crippled. For one thing, I cannot see the editor. It just doesn't appear when I open a file, even though the title bar and the status bar both indicate an open file. Additionally, dragging a dockable pane invariably results in an immediate crash.
On what OS are you testing?Sorry, should've mentioned that...I'm using Windows 98SE.
I tried this, and it helped for a short time. The "Start here" page appeared when I reverted to the built-in default layout, and I could open files in the editor. But I still keep getting a lot of random crashes, and the "Start here" page doesn't always go away when I open a project. At least it's more or less usable, though. Still, I think I may just stick with my old ANSI SVN version (the one posted earlier in this thred). For some reason, the MSLU-enabled compilation just seems too unstable.QuoteBut the program I got was very crippled. For one thing, I cannot see the editor. It just doesn't appear when I open a file, even though the title bar and the status bar both indicate an open file. Additionally, dragging a dockable pane invariably results in an immediate crash.
Whenever you see layout-related errors, try deleting your active layout (or switch to another one if you have).
"View->Layouts->Delete current".
this weekend I will create a new specific ansi build !!:D :D
Is there anything special involved, other than just changing the unicode suffix and removing the unicode #define?you need a wxWidgets ansi build :)
Right, obviously. 8) I meant from the C::B end of things.Is there anything special involved, other than just changing the unicode suffix and removing the unicode #define?you need a wxWidgets ansi build :)
i meant, "no nothing" just the wxwidgets ansi build in addition to your suggestionRight, obviously. 8) I meant from the C::B end of things.Is there anything special involved, other than just changing the unicode suffix and removing the unicode #define?you need a wxWidgets ansi build :)
@Yiannis : could you always add them to the target ? Then for win98 this is already ok, only need to turn off then unicode define/suffix then.
for the sdk target :
libshfolder.a
libshell32.a
I can't confirm or 'dis'confirm :-(
I just compiled rev1836 on Win98SE. With shfolder linked into the src target, I got an error about codeblocks.dll using an undefined function. When I linked shfolder into the sdk target instead, it worked fine. It appears Lieven was right about Therion's and Ceniza's conclusions.I can't confirm or 'dis'confirm :-(
OK, added it in the src target 'cause that's where it should be IMHO. If this doesn't work, it's still easy to move them in the sdk target ;)
r1822.