It must give me full access to the underlaying API of the OS i am targeting without restriction.
It must not write the code for myself.
Thus the list is very short:
- It must be able to create native EXE and DLL for the current Windows platform (at this time 32 and 64-bit).
- It must be able to create static Library.
Support for managed code, is a plus, but not a mandatory, everything else i don't care.
...
Let me add few things:
- it must be reliabel and if i have bugs in my code i must be sure its not bugs in the compiler.
- it must under all circumstnaces help me on compile-time errors to fix them
- at least tell me in which file and in which line these errors are.
- i would love to have a unlimited Macro nesting depth
- ASM support may not be needed for everybody, but is for me a YESYES if its there and a NONO if its missing.
Theo,
I also need a few in-line ASM, thus consider it is in my "short" list. ;)
...
Hi,
you should be able to register directly transferred
Z.B call sub (eax, ebx, ecx, edx)
There should be no scaffolding functions as with Free Basic.
Example:
sub test naked ()
end sub
Regards,
Peter
64bit ASM support?
Granted my 32bit asm was not great but I could not get my head around 64bit. I finally just gave up and resolved myself to polishing up my 32bit knowledge.
James
James,
By all means i am not an ASM expert, i am just using it in some critical section of my code.
Like this simple matrix function from GDImage, that was given to me by one of the ASM Guru floating around here:
SUB MatrixMul5x5FPU(BYREF mr() AS SINGLE, BYREF m1() AS SINGLE, BYREF m2() AS SINGLE )
DIM p AS SINGLE PTR
p=VARPTR(m1(0))
! mov ecx,eax
p=VARPTR(m2(0))
! mov edx,eax
p=VARPTR(mr(0))
block:
! call column
! call column
! call column
! call column
! call column
EXIT SUB
column:
! call cell
! call cell
! call cell
! call cell
! call cell
! add edx,20
! sub ecx,20
! ret
cell: ' row A * column B
! fld dword ptr [ecx ]
! fmul dword ptr [edx ]
! fld dword ptr [ecx+20]
! fmul dword ptr [edx+04]
! fld dword ptr [ecx+40]
! fmul dword ptr [edx+08]
! fld dword ptr [ecx+60]
! fmul dword ptr [edx+12]
! fld dword ptr [ecx+80]
! fmul dword ptr [edx+16]
! faddp st(1),st(0)
! faddp st(1),st(0)
! faddp st(1),st(0)
! faddp st(1),st(0)
! fstp dword ptr [eax]
! add eax,4
! add ecx,4
! ret
END SUB
...
Patrice,
I don't know who your guru was but if was Hutch I don't think he is doing much with 64bit??
His baby is Masm32.
You may just have to hire out :)
James
Yes, HE CAN!
I asked him on ASM x64:
See my Interview with Hutch the ASM-Guru:
http://www.jose.it-berater.org/smfforum/index.php?topic=3695.msg12145;topicseen#msg12145
Patrice,
I'd say your best bet for a professionally supported compiler for x64 code would be Visual C++, and if you get Visual Studio 2010 Professional (which is actually quite nice) you'll basically get everything you wanted there including the ability to generate managed code. The only thing that you won't get is the ability to write inline x64 assembly, but you can use a tool like Yasm for that if you're really interested in porting over some over x86 assembly.
There's also Pelles C, LCC and WPG (MinGW) if you're looking for something on the cheap(er) end of things, but given that what you're doing is commercial development, I'd argue that Visual Studio is the way to go here if you need x64 support right away. Of course, the caveat to all of that is how comfortable you are with C/C++.
Edit: I'm not exactly sure what you mean by "it must not write the code for myself" but I thought I'd mention that although VS does have wizards and code templates, using them is completely optional. You're free to create an empty or skeleton project as you wish and code everything from the ground up.
Mike,
QuoteI'm not exactly sure what you mean by "it must not write the code for myself"
For me that would say:
"
a compiler is not a third party addon, nor a code editor, nor a form designer, and it must avoid using a proprietary syntax to encapsulate the low level API".
For me a compiler must support the current technology of the platform it is running on,
nothing more,
nothing less.
But, when i write "current technology" i have a tolerance of say: 3 or 4 years maximum. Go figure :)
...
Well, you could just use the command-line compiler, but I have to ask: why the issue with any compiler that comes with an IDE? Or to be more specific, have you ever worked with an IDE like Visual Studio or Eclipse? If you're just used to PB and maybe some 3rd party code editors, it might take a little bit of getting used to, but once you've started getting comfortable with it, I'd bet you would find yourself being a lot more productive than using a bunch of different tools (and that scales up as your project becomes more complex).
Of course, as far as encapsulating the API, that's pretty much a non-issue with any C compiler. With C++ there's MFC, but again, there's absolutely no requirement that you use it (just as you don't have to use any of the DDT stuff in PB).
Edit: Then again, I have to say that I think it's a bit odd that you're talking about encapsulating the API and managed code in the same breath. I mean, managed .NET code is nothing but a massive encapsulation of the API along with a ton of other high-level classes. Anyway, if you haven't worked with VS2010, I still say you should try it (their eval is 60 days) and give yourself some time to really work with it and get over any initial learning curve. Join the Borg collective with the rest of us.. resistance is futile! ;)
Mike,
I am using already VISUAL STUDIO (see my C# corner section), and I am also using a RAD tool when i need one (see my WinDev section).
However i do not espect from a bare compiler to be a RAD tool nor something as complex as VS.
I don't like managed code, because it is a black box, and i don't like either the obscurification of the C++ classes.
However "resistance is futile", and perhaps it is time for me to leave my compiler of choice. :(
...
If you're already using Visual Studio, then you have your 64-bit solution right there. And keep in mind that you don't need to use C++ and MFC. You can easily create DLLs using plain 'ol C and the Visual C++ command line compiler (cl.exe) if you want. So if building everything by hand using your favorite text editor, creating makefiles and all that good stuff is what you prefer, that's completely doable with what you've already got.
Mike,
I shall probably come back to you, to learn more about the use of C++ and un-managed code, because i mostly used VISUAL STUDIO with Dot.NET and C#.
Thanks for the heads up.
...
Sure, feel free to post or send me a PM or email (you have my address right?) and I'm happy to help however I can.
Mike,
Do you know if "VISUAL C++ 2010 Express" is able to create both plain Win32 and 64-bit DLL?
...
Reading here
http://msdn.microsoft.com/en-us/library/9yb4317s.aspx (http://msdn.microsoft.com/en-us/library/9yb4317s.aspx)
the answer is yes, but you must install the Windows Software Development Kit (SDK) too.
Tiziano beat me to it, so for sure you can create standard x86 and x64 DLLs. What I'm not sure of is whether or not you have direct access to the 64-bit compiler in the VS IDE (i.e.: whether the express edition supports configuration for x64 projects), but from what you've described earlier, the command line compiler is all you're really interested in anyway.
Also, unless something has changed recently, it's not even really necessary to install the Express edition if you just want the C/C++ compiler. The Windows SDK includes two installer packages, vc_stdx86.msi and vc_stdamd64.msi which are the x86 and x64 command line compilers, respectively. With Visual Studio, what you're really paying for there is the IDE and all of the project management and testing tools; Microsoft has given away their core compiler toolchain for free in various forms for quite a while now.
In terms of creating the DLLs themselves, you could use either C or C++, but I tend to personally prefer using standard C for that; on the other hand, for COM components, you're nuts (or at least have a serious masochistic streak) if you don't use C++ with ATL.
You could also use what I am using.
http://basic-compiler.com/forum/index.php?board=39.0
James
Hi Patrice,
Have a beta version of Visual Studio 2010th Just as it looks it support x64 and x86 code. At least you can set it in the compiler options. But I can not imagine that it is not.
Regards Peter
Hello James
Have looked at the BCX Converter shortly. He seems to be interesting.
Regards,
Peter ;)
Quote from: Peter Weis on June 13, 2010, 12:55:54 AM
Hi Patrice,
Have a beta version of Visual Studio 2010th Just as it looks it support x64 and x86 code. At least you can set it in the compiler options. But I can not imagine that it is not.
Regards Peter
IIRC, the VS2010 beta builds were effectively the Professional editions, so they had all of the bells and whistles turned on. The Express editions are a little different in that they're geared more towards students and hobbiest programmers.
So far i have used heavily PB, because the syntax is so closed to WinDev running in English mode,
that i can port all my examples between them, in a few days work.
For my DLLs, this is rather much complex, because while i am using exclusively plain SDK style to be 100% compatible with the core API,
there is much more code editing to convert everything to the C syntax.
Idealy I should have first to write a PB to C converter to automate things as much as i can, before to fine tune everything by hand.
I shall give a try to Kev's BCX, or perhaps do you know of another one?
...
The link up a few posts here in this thread to BCX is an open source BASIC to C converter. I've never used it, so I couldn't even begin to tell you how well it would work with your PowerBasic code or what kind of C code it generates. In my personal experience, converters in general may get you 80-90% of the way there, but there's always cleanup and stylistically the converted code is usually pretty funky.
Using a converter may be worth checking out in the short-term, but over the long term I think you'd ultimately be better served by rewriting your code, rather than converting it. It's kind of like the difference between using Google to translate your website into German, or actually learning German and performing the translation yourself (or paying someone to translate for you). The first option is fast and easy, but the results are typically poor. The second takes more time, but you end up with a much better result.
Edit: The only other converters I'm aware of are Bacon and b2c for Linux, and I'm pretty sure they'd have no idea what to do with PowerBasic's syntax, particularly when it comes to calling Windows API functions.
I thinkElias is also working on something like that.
His Editor converts all sort of things ... php-BASIC-C, but i don't know the details.
Besides that he seems still be interested in somebody to help him to get it on the market.
Maybe you want to talk to Elias (EGRID32)?
I posted the link primarily to make aware of the cross compiling MinGW compilers.(there are even Linux hosted ones).
I slid into the 64bit stuff sideways as I was looking for Linux/Windows single source using wxWidgets. I mostly accomplished that with BcxWx. There is no need to use Bcx if you prefer, and know c/c++. I just found this setup pretty easy to setup and use.
I realize the batch files probably need some work as my knowledge of MinGW g++ is lacking.
James
I have been working on a Basic compiler, for the last 30 months or so, which I believe will match Patrice's requirements for a bare bones compiler very closely. The core language is almost complete and it can now produce 64 bit executables and access the Windows API using the x64 calling convention. These executables are currently restricted to assembly code while I adapt the Basic encodings for this platform.
At the present rate of progress, Oxygen should reach its beta mark in about 6 to 9 months time. But if any of you are interested, I can create a board and make alpha postings of the project as I have been doing for thinBasic. The feedback would be very welcome!
Charles
Charles,
Please Do. I am a Basic fanatic and from what I've see of your tboxygen code I know it will also suit my quest for oop.
James
I don't have a 64 bit OS, but I applaud the initiative.
One curiosity of the 64 bit platform: The DLLs still have the same names KERNEL32.DLL USER32.DLL etc. :)
The header declarations look very similar but the underlying calling convention is totally different. And all handles and pointers must be dealt with as full 64bit entities. Apart from these, INTEL/MS have designed the 64 bit scheme to make migration as easy as possible.
Charles
James,
I just made a try with BCX, i can't get it to work on Windows7 64-bit (none of the GUI examples).
I did try to translate a PB file using BCX (by hand), and it reports an error when it comes to this simple declaration:
DECLARE FUNCTION SendMessage LIB "USER32.DLL" ALIAS "SendMessageA" (BYVAL hWnd AS DWORD, BYVAL dwMsg AS DWORD, BYVAL wParam AS DWORD, BYVAL lParam AS LONG) AS LONG
...
Patrice,
Could you try that again with quads and qwords. All handles and pointers must be 64bits wide. And all Parameters are passed in 64 bit registers or 64 bit stack locations regardless of their nominal size.
Charles
I think he's saying that the parser doesn't understand how to deal with the function declaration, although you're correct that declaration is completely wrong for 64-bit Windows.
Patrice, you're not going to be able to a straight conversion like that to 64-bit code using those PowerBasic declarations. Many of them simply won't work (your program will crash) because they're written to assume that things like handles, pointers, window parameter arguments (wParam and lParam) and various return values are 32-bit when they're not on an x64 system. For example, every function that returns an LRESULT is returning a 64-bit value; if you look in the C headers for the Windows API, LRESULT is defined as 64-bits on an x64 system.
Bottom line, if you're using functions as they're declared in PowerBasic, even if the converter was able to cope with the function declaration itself your code would still break because the function parameters and return value are all the wrong sizes. If you need to go 64-bit, I think you're going to need to bite the bullet and rewrite.
Edit: I thought I'd add a link to the Windows API data types (http://msdn.microsoft.com/en-us/library/aa383751(VS.85).aspx) just as a point of reference. Wherever you see things typed as *_PTR (e.g.: LONG_PTR, INT_PTR, etc.) that means it's a value that is large enough to hold an address. So, for example a LONG is 32-bits on both x86 and x64 versions of Windows, but a LONG_PTR is 32-bits on x86 and 64-bits on x64. This was done primarily for those API calls where parameters were treated as integers but could be (or always were) actually values cast from pointers. Another example is a lot of the enumeration APIs in Windows allowed you to pass in a user-defined LONG or DWORD value that would then be handed back to the enumeration function; Microsoft changed all those to LONG_PTR and DWORD_PTR to allow for the programmer to pass in a pointer as well as arbitrary integer values.
At this time i didn't even try to convert to 64-bit, but to 32-bit first, just to see how good BCX is to translate from PB to C, nothing else... ???
...
Any code converter that's going to do what you need would have to have an intrinsic understanding of the complete Windows API (and DirectX and whatever else... so you're talking about tens of thousands of functions it would need to be aware of). Even if it understood the function declaration syntax in PowerBasic, converting solely based on the existing PB declarations would result in the creation of incorrect C prototypes. In other words, the converter would need to recognize that SendMessageA was really a Windows API function, ignore the actual declaration and convert your code based on how SendMessage should be called in C/C++. Obviously, it couldn't do this with functions that it didn't recognize as part of the API and would have to convert them as-is (and you're back to the problems described above).
In Oxygen I am using an abstract datatype Sys which is 64 bits wide on an a x64 system and 32 bits otherwise. I hope this will help in making code cross compatible between the two systems.
Directly interpreting C headers is also possible though I am sure there a quite a few nasties out there I have yet to encounter!
Charles
Mike,
BCX was written first by Kevin Diggins, that some of us may have known in the past on compuserve and/or the old PowerBASIC forum.
This is the reason why i give him some credits, he must know a little how to convert PB into C. ;)
You don't have to declare any of the winapi functions but you do have to use the correct abstract "c/c++" data types:
HWND,HINSTANCE,HDC etc. That is why most of the original bcx gui examples will not compile with g++. g++ is very strict on the naming.
A window is not s HANDLE it is a HWND for example. All the bcx gui example code was written for a very lax pelles compiler.
James
It doesn't look like BCX is really an implementation of the PowerBasic syntax. For example, it looks like the equivalent of the DECLARE FUNCTION syntax is called C_DECLARE. Just browsing through the documentation, I get the impression the BCX is not really a "converter" in the sense that it's something to be used to perform a one-time conversion of BASIC source code to C. It's really more of a variant of BASIC in its own right, but instead of being its own compiler, it internally translates that BASIC code into C and passes it off to a C compiler.
In other words, BCX appears to be designed with the goal that you keep developing and maintaining your code in BASIC, and it acts more like a font-end preprocessor in the toolchain. It doesn't appear to be a tool that's really geared towards migrating you away from BASIC to C, where all subsequent development is done in C after the conversion process. It's not clear from the documentation whether BCX is 64-bit aware or not, there doesn't seem to be any explicit mention of it. I'm guessing that its not because functions like STRPTR explicitly talk about returning 32-bit pointers.
Here is some familiar code that will produce either 32 or 64 bit by just changing the $ONEXIT parameter.
James
$CPP
$ONEXIT "GW64.BAT $FILE$"
' **************************************************************
' A neat little demo written by Jules Marchildon for PBDLL
' Modified for BCX version by Kevin Diggins
' **************************************************************
GLOBAL hDemo AS HWND
GLOBAL hInstance AS HINSTANCE
GLOBAL hOldFont AS HANDLE
GLOBAL hMyFont AS HANDLE
GLOBAL AppName$
GLOBAL zText$
FUNCTION WINMAIN
Local Wc AS WNDCLASS
Local Msg AS MSG
AppName$ = "BCX_Neat"
hInstance = hInst
Wc.style = CS_HREDRAW OR CS_VREDRAW
Wc.lpfnWndProc = WndProc
Wc.cbClsExtra = 0
Wc.cbWndExtra = 0
Wc.hInstance = hInst
Wc.hIcon = LoadIcon ( NULL,IDI_APPLICATION )
Wc.hCursor = LoadCursor ( NULL, IDC_ARROW )
Wc.hbrBackground = CreateSolidBrush(RGB(255,0,0))
Wc.lpszMenuName = NULL
Wc.lpszClassName = AppName$
RegisterClass(&Wc)
hDemo = CreateWindow ( AppName$, "BCX", WS_CAPTION OR WS_SYSMENU, _
0, 0, 400, 200, HWND_DESKTOP, NULL, hInst, NULL)
Center (hDemo)
Show (hDemo)
While GetMessage (&Msg,NULL,0,0)
TranslateMessage (&Msg)
DispatchMessage (&Msg)
Wend
Function = Msg.wParam
End Function
FUNCTION WndProc ()
LOCAL hRgn1 AS HRGN
LOCAL hRgn2 AS HRGN
LOCAL rc AS RECT
LOCAL hDC AS HDC
SELECT CASE Msg
CASE WM_CREATE
hDC= GetDC(hWnd)
zText$ = "BCX!"
hMyFont = CreateFont (200,0,0,0,1000,FALSE,FALSE,FALSE,ANSI_CHARSET, _
OUT_CHARACTER_PRECIS,CLIP_DEFAULT_PRECIS, _
PROOF_QUALITY,FIXED_PITCH,"Courier New" )
hOldFont = SelectObject(hDC,hMyFont)
CALL BeginPath(hDC)
CALL TextOut (hDC, 0, 0, zText$, LEN(zText$))
CALL EndPath (hDC)
hRgn1 = PathToRegion ( hDC )
CALL GetRgnBox ( hRgn1, &rc )
hRgn2 = CreateRectRgnIndirect( &rc )
CALL CombineRgn(hRgn2, hRgn2, hRgn1, RGN_XOR) ' <<<-- Try RGN_AND
CALL DeleteObject(hRgn1)
CALL ReleaseDC(hWnd,hDC)
CALL SetWindowRgn(hWnd, hRgn2, 1)
CALL SelectObject(hDC,hOldFont)
EXIT FUNCTION
CASE WM_LBUTTONDOWN
CALL ReleaseCapture
CALL SendMessage (hDemo,WM_NCLBUTTONDOWN,HTCAPTION,0)
EXIT FUNCTION
CASE WM_RBUTTONUP
SendMessage (hWnd,WM_DESTROY,wParam,lParam)
EXIT FUNCTION
CASE WM_DESTROY
PostQuitMessage (0)
EXIT FUNCTION
END SELECT
FUNCTION = DefWindowProc (hWnd,Msg,wParam,lParam)
END FUNCTION
Mike,
The 32/64 is NEW. like less than a week and came about by me finding the new MinGw32/64 cross compilers. It's a real new learning experience for me bcx,c++,g++ specific, 32/64.. wxWidgets ... I'm tired....
James
Quote from: James C. Fuller on June 14, 2010, 09:11:31 PM
The 32/64 is NEW. like less than a week and came about by me finding the new MinGw32/64 cross compilers. It's a real new learning experience for me bcx,c++,g++ specific, 32/64.. wxWidgets ... I'm tired....
Ah, that would explain why it's not mentioned. Am I right though that BCX is really designed to function as a language you develop in, rather than just a one-shot conversion tool? That's the impression that I got when I was reading through the docs online. That being the case, it sounds like an option for Patrice would be to just focus on modifying his PowerBasic source code to use the BCX syntax and he could stick with keeping his code largely in BASIC rather than a wholesale conversion to C/C++.
Quote from: Mike Stefanik on June 14, 2010, 09:17:28 PM
Quote from: James C. Fuller on June 14, 2010, 09:11:31 PM
The 32/64 is NEW. like less than a week and came about by me finding the new MinGw32/64 cross compilers. It's a real new learning experience for me bcx,c++,g++ specific, 32/64.. wxWidgets ... I'm tired....
Ah, that would explain why it's not mentioned. Am I right though that BCX is really designed to function as a language you develop in, rather than just a one-shot conversion tool? That's the impression that I got when I was reading through the docs online. That being the case, it sounds like an option for Patrice would be to just focus on modifying his PowerBasic source code to use the BCX syntax and he could stick with keeping his code largely in BASIC rather than a wholesale conversion to C/C++.
You are correct. Bcx is a programming language whose backend is c/c++ code.
Maybe anymore discussion should move to the Bcx board: http://www.basic-compiler.com/forum/
James
James
QuoteMaybe anymore discussion should move to the Bcx board
We can also speak of BCX here, because this is a "discussion" thread, and the information would benefit to all those who are concerned.
...
Mike,
I have upgraded to VISUAL STUDIO 2010 Pro 8)
More than three years that i haven't written a single line of C# code, looks like i have forgotten everything :)
...
Hi Patrice,
To me it was so when I with Power Basic for Windwos when I started, after a long time with Power Basic again. As I know you, you'll get the fast in the grip. Must take care of you do not like in Power Basic to the whole area as in Power Basic. But a switch is always connected to work sustainably. It's annoying for you, that you at Power Basic is no alternative offered to you for that. Thank God I do not have to change!
Peter greetings ;)
No worries, it's like riding a bike. It might be a while, but it'll all come back to you. I think once you get used to the IDE (again) you'll really enjoy working with it. I think the Visual Studio IDE is really the best out there, but it can take some time to work out all of the features and how everything works vis a vis solutions, project options, multi-targeted builds, etc. There are some areas where the compilers could be improved, namely with Microsoft's selective support for the C99 standard and upcoming changes with C++0x. Although, to be fair, there's not really any mainstream compiler that supports everything, and C++0x is not a finalized standard. The one weak area with 2010 is the new and not-so-improved help system. I'd recommend downloading the Visual Studio Help Viewer addon, we have some info about it on our forums:
http://forums.catalyst.com/viewtopic.php?f=35&t=1336
In house, we still primarily use Visual Studio 2008 but we'll probably plan on migrating existing projects to 2010 sometime later this year. For now, we primarily use it to build .NET 4.0 assemblies.
Not to fire again 32/64 bits discussion but I saw this interesting article mentioned in PB forum by Bernhard Fomm:
http://windowsteamblog.com/windows/b/bloggingwindows/archive/2010/07/08/64-bit-momentum-surges-with-windows-7.aspx
From everything I've read, that's been pretty much true since Windows 7 was released; of course, you have to keep in mind that all versions of Windows 7 still only accounts for about 14% of the overall market, and Vista is about 15%. The total number of 64-bit Windows systems out there are still <10% of total marketshare. The 32-bit version of Windows XP still accounts for >60% of all Windows systems.
With the release of Windows NT in 1993, the first truly 32-bit version of Windows, it took about a decade to transition away from 16-bit code. Windows XP x64 was released in 2005 (it was actually the Windows Server 2003 kernel, repackaged), so even if it follows along that same trajectory, we're looking at another 5 years. Of course, it's also the case that there's not as much of a compelling business interest in making the shift to 64-bit code. Remember that one of the things that finally got a lot of companies to dump their old 16-bit applications was the Y2K issue, where they were already in the mode of replacing hardware and upgrading software. That kind of impetus just doesn't exist today, so I suspect the adoption rate (by business) is going to be slower than the move from 16-bit to 32-bit.
Mike, remember that even now, nearly all standalone PC's you buy have more memory (RAM) that a 32 bit OS can handle. Thats a different situation from the 16/32 switch time.
Quote from: Theo Gottwald on July 10, 2010, 07:05:55 AM
Mike, remember that even now, nearly all standalone PC's you buy have more memory (RAM) that a 32 bit OS can handle. Thats a different situation from the 16/32 switch time.
You're thinking about home and gaming systems. If you look at business desktops (for example, the Dell Vostro and Optiplex lines), you'll see that most of those computers (the ones that sit on the desks of secretaries, accountants, etc.) come with 2GB of memory and downgrade rights to Windows XP. I've said this before -- don't confuse what you see with popular home computer lines from Dell, HP, etc. with the reality that the vast, vast majority of Windows desktops out there are
business computers, running on trailing-edge hardware. In the business IT world, they are
not early adopters, and they don't tend upgrade hardware or operating systems unless they absolutely have to in order to meet a specific need of their business.
I wrote about this on the PB forums, but when Microsoft reminded folks that Windows XP SP2 reaches end-of-life on July 13th, estimates (as of April this year) are that about 80% of businesses in the United States were still running XP SP2 as their primary operating system. Those folks are not going to be jumping on the 64-bit bandwagon any time soon. It's just not going to happen.
Edit: By the way, I don't want to give the impression that 64-bit development isn't useful; it's just that at this point it's nowhere near critical mass. When you start seeing widespread adoption of Windows 7 64-bit by businesses, then you'll see a real shift. At this point in the timeline, I'd say the move to 64-bit computing is about where 32-bit was when Windows 95 was released. My personal guestimate is that it's going to be another 5-8 years before we see a substantial move away from 32-bit code. Whenever you consider this, just keep in mind that the real drivers in the Windows desktop market are businesses, not home users.
Mike,
QuoteI don't want to give the impression that 64-bit development isn't useful; it's just that at this point it's nowhere near critical mass
Programming embrass all the scope of human activity, a modern compiler must address the
programmer's current need, that's all.
I am working today on the new features that would be part of my addons in one or two years, like a car manufacturer is working in 2010 on the model that would be sold in 2014.
...
>Programming embrass all the scope of human activity, a modern compiler must address the programmer's current need, that's all.
Hmm sounds kinda spoiled, i guess this is because many of the newer tools provide 64 bit support and even for free, yes we all are spoiled with that.
It's also odd that we 'approve' end-users to keep working with DOS bassed accountancy apps while we at the other end have a 'must-have' feeling regarding the compiler.
We support database-reading for old DOS apps, how can it be different?
(The lengths i went to to make it work..)
I understand your urge but would also want to stress that most of the programmers care much less for 64 bit.
Even worse, when i go to a 64 bit PowerBASIC executable.., how would i communicate with older ODBC drivers and such?
I am not so sure it will all work so well.
Imo you are in the 'latest-gadget' area, i mean the graphic support you offer.
It may well be only a few programmers are working in that area.
If i have a 32 bit app in need of calling once in a while 64 bit odbc driver i can still work it out, with graphics you won't.
I suspect that there will be a big gap between 32 bit apps and 64 bit apps for many many years, i mean for only targeting to a specific area.
Windows 7: 46% of all sold Computers use Window 7/64WinFuture - Message (http://winfuture.de/news,56716.html)
QuoteMicrosoft führt die zunehmende Verbreitung der 64-Bit-Ausgaben von Windows 7 unter anderem auf gesunkene RAM-Preise zurück, wodurch die PC-Hersteller ihre Systeme mit mehr Arbeitsspeicher ausstatten können. Außerdem unterstützen die meisten heute verfügbaren Prozessoren 64-Bit-Betriebssysteme und die Zahl der kompatiblen Geräte steigt stetig.
Die PC-Hersteller setzen mittlerweile voll auf 64-Bit. So haben einige Anbieter ihre gesamte Produktpalette umgestellt, weshalb laut Marktforschern 77 Prozent der in den USA verkauften neuen Computer bereits mit einer 64-Bit-Version von Windows 7 daher kommen. Auch im Business-Bereich wird auf Windows 7 64-Bit umgestellt, rechnen Marktforscher doch damit, dass schon 2014 75 Prozent der amerikanischen Firmen eine solche Version einsetzen werden.
Yesterday i have read an article in a computer magazine, which has tested the new "Delphi" Compiler.
They said that after all this company should quickly deliver a 64-bit version or it may be overrun by the competitors, soon.
Maybe i am overreacting as well, just read about w7 64 bits being sold so much, it may well be that several 32 bit drivers work fine in such an os.
That i don't know.
Hopefully since i would like to make the jump at some point, the prospect of having an improved memory management is attempting :)
I guess i'll make the jump with w8 or so.
I couldn't imagine myself developping third party addons, without checking them on the latest available Windows version.
This is how i realised that i couldn't use anymore, something as simple as, the EnumChildWindow, when the target window is a 64-bit application, for example with the "#32769" desktop.
Added:
To ease the translation from 32-bit to 64-bit, WinDev uses this syntax:
gnParent is system int = Handle("MyWindow")
this means gnParent will be either 32 or 64-bit whatever the OS being used, simple isn't it?
(Note: WinDev itself is C++, and it works a little like BCX or managed C# if you prefer the OOP syntax)
....
Quote from: Theo Gottwald on July 11, 2010, 07:48:37 AM
Yesterday i have read an article in a computer magazine, which has tested the new "Delphi" Compiler.
They said that after all this company should quickly deliver a 64-bit version or it may be overrun by the competitors, soon.
In truth, they've already been "overrun" by Microsoft quite a while ago. Embarcadero/CodeGear is several steps behind in both their native and .NET compilers. From what I've read, they've been focusing on cross-platform support, and won't have a 64-bit compiler until at least 2012.
Edwin, just so you know, you can't use 32-bit drivers in 64-bit versions of Windows. Drivers need to be 64-bit, and they need to be digitally signed using KMCS (kernel mode code signing). For logo compliance, the driver also needs to be submitted to Microsoft for WHQL certification.
Quote from: Patrice Terrier on July 11, 2010, 01:52:46 PM
This is how i realised that i couldn't use anymore, something as simple as, the EnumChildWindow, when the target window is a 64-bit application, for example with the "#32769" desktop.
I'm not sure why you think this, is it because of the size of the window handle? A 32-bit process can enumerate windows that belong to a 64-bit process without a problem, and can even send those windows messages. Although the handles on an x64 system are 64-bit, only the lower 32 bits are significant; the upper 32 bits are always zero. It's perfectly safe to cast a 64-bit handle to a 32-bit integer and back again (as long as it's an actual handle, not a pointer).
32-bit and 64-bit processes can send Windows messages to each other, use RPC and other IPC mechanisms, and with some limitations, can share memory. The only sticking point is if pointers are being used; for example, Windows messages that expect pointers to be passed in the LPARAM argument won't work because they'll be truncated.
http://msdn.microsoft.com/en-us/library/ee872017.aspx
Mike,
I am speaking of pointer of course.
I am doing interprocess communication with the undelaying OS using:
VirtualAllocEx
OpenProcess
WriteProcessMemory
ReadProcessMemory
Example of problematic code:
SUB CreateShortCut(BYVAl hWnd AS LONG)
LOCAL nFound, nCount, nLeft, nRight, nHeight, hBitmap AS LONG
LOCAL K, nItemCount, nCenter AS LONG, sLink, sUseThumb AS STRING
LOCAL rw AS RECT
gnXoffset = 0
IF UBOUND(gS) > 0 THEN '// Clear existing bitmap
FOR K = 1 TO UBOUND(gS)
IF gS(K).hBitmap THEN DeleteObject(gS(K).hBitmap): gS(K).hBitmap = 0
NEXT
END IF
nCenter = (gS(0).w - 48) \ 2
ghProgMan = FindWindow("Progman", "Program Manager")
ghListView = FindWindowEx(ghProgMan, 0, "SHELLDLL_DefView", "")
ghListView = FindWindowEx(ghListView, 0, "SysListView32", "FolderView")
nItemCount = SendMessage(ghListView, %LVM_GETITEMCOUNT, 0, 0)
IF nItemCount THEN
LOCAL dwProcessId, hProcess, dwSize, lpData AS DWORD
CALL GetWindowThreadProcessId(ghListView, dwProcessId)
hProcess = OpenProcess(%PROCESS_VM_OPERATION OR %PROCESS_VM_READ OR %PROCESS_VM_WRITE, %FALSE, dwProcessId)
IF hProcess THEN
'// Compute the size of our reserved memory buffer
dwSize = SIZEOF(POINTAPI) + SIZEOF(LVITEM) + %MAX_PATH * 2
lpData = VirtualAllocEx(hProcess, BYVAL %NULL, dwSize, %MEM_COMMIT, %PAGE_READWRITE)
IF lpData THEN
LOCAL pWsh AS IWshShell
pWsh = NEWCOM "WScript.Shell"
LOCAL pLnk AS IWshShortcut
' Shortcut description: ACODE$(pLnk.Description)
' Shortcut working directory: ACODE$(pLnk.WorkingDirectory)
' Shortcut arguments: ACODE$(pLnk.Arguments)
' Shortcut hot key: ACODE$(pLnk.HotKey)
' Shortcut icon location: ACODE$(pLnk.IconLocation)
' Shortcut target path: ACODE$(pLnk.TargetPath)
' Shortcut window style: FORMAT$(pLnk.WindowStyle)
LOCAL sDeskTopPub, sDeskTopAdm, sTempPath AS STRING
'sDeskTopTray$ = zsFolderGet(&H000A) '// %CSIDL_BITBUCKET ' <desktop>\Recycle Bin
' %CSIDL_STARTMENU = &H000b ' <user name>\Start Menu
' %CSIDL_DESKTOPDIRECTORY = &H0010 ' <user name>\Desktop
sDeskTopAdm = zsFolderGet(%CSIDL_DESKTOP)
sDeskTopPub = zsFolderGet(%CSIDL_COMMON_DESKTOPDIRECTORY)
sTempPath = zGetTempPath()
'// Setup pointers
LOCAL lpPosition, lpItem, lpText, nIconVisibleAtOnce AS LONG
lpPosition = lpData
lpItem = lpData + SIZEOF(POINTAPI)
lpText = lpData + SIZEOF(POINTAPI) + SIZEOF(LVITEM)
LOCAL lvi AS LVITEM
LOCAL szTxt AS ASCIIZ * 128, szLnk AS ASCIIZ * (%MAX_PATH * 2) ' Allow room for unicode
LOCAL DoLnk AS LONG
CALL GetWindowRect(hWnd, rw)
nHeight = (rw.nBottom - rw.nTop) - 75
FOR K = 0 TO nItemCount - 1
'// Init LVITEM structure and copy it to our reserved memory buffer
lvi.mask = %LVIF_TEXT
lvi.iItem = K
lvi.iSubItem = 0
lvi.pszText = lpText
lvi.cchTextMax = %MAX_PATH * 2
CALL WriteProcessMemory(hProcess, lpItem, lvi, sizeof(LVITEM), 0)
'// Get text label and x,y location
CALL SendMessage(ghListView, %LVM_GETITEMTEXT, K, lpItem)
CALL SendMessage(ghListView, %LVM_GETITEMPOSITION, K, lpPosition)
'// Copy from process memory to local variables
szTxt = ""
CALL ReadProcessMemory(hProcess, lpText, szTxt, SIZEOF(szTxt), 0)
LOCAL p AS POINTAPI
CALL ReadProcessMemory(hProcess, lpPosition, p, SIZEOF(POINTAPI), 0)
IF LEN(szTxt) THEN szLnk = szTxt + ".lnk"
IF ISFILE(sDeskTopAdm + szLnk) THEN
sLink = sDeskTopAdm + szLnk
ELSEIF ISFILE(sDeskTopPub + szLnk) THEN
sLink = sDeskTopPub + szLnk
ELSE
sLink = ""
END IF
sTarget$ = ""
IF LEN(sLink) THEN
DoLnk = -1
pLnk = pWsh.CreateShortcut(UCODE$(sLink))
'sTarget$ = PARSE$(ACODE$(pLnk.IconLocation), 1)
'IF LEN(sTarget$) = 0 THEN sTarget$ = ACODE$(pLnk.TargetPath)
sTarget$ = RTRIM$(ACODE$(pLnk.TargetPath))
IF LEN(sTarget$) = 0 THEN sTarget$ = ResolveLnk((sLink))
'// Hide the own OTB shorcut
IF LCASE$(sTarget$) = LCASE$(EXE.FULL$) THEN sTarget$ = ""
ELSE
DoLnk = 0
sTarget$ = ResolveShortcutName(szTxt)
END IF
IF LEN(sTarget$) THEN
INCR nFound
IF CreateBarIcon((sTarget$), nFound) THEN
INCR nCount
REDIM PRESERVE gS(%LBOUND TO nCount)
gS(nCount).y = nHeight: gs(nCount).scale = %SCALE_DEFAULT: gS(nCount).opacity = 255
sUseThumb = sTempPath + "OfTheBay" + STR$(nFound) + ".png"
gS(nCount).hBitmap = CreateDockIcon((sUseThumb), gS(nCount).w, gS(nCount).h)
CALL zKillFile((sUseThumb))
IF DoLnk THEN gS(nCount).ShellTo = LCASE$(ACODE$(pLnk.TargetPath))
IF DoLnk THEN gS(nCount).WorkDir = ACODE$(pLnk.WorkingDirectory)
gS(nCount).UseLabel = szTxt
IF DoLnk THEN gS(nCount).ShowCmd = pLnk.WindowStyle
gS(nCount).focusXY = MAKLNG(p.X + 10, p.Y + 10)
END IF
END IF
NEXT
'// Freeup memory
CALL VirtualFreeEx(hProcess, lpData, 0, %MEM_RELEASE)
' ****************************************************
CALL ReadCustomShortcuts(nFound, nCount, nHeight, p)
' ****************************************************
'// Setup icon x location
nIconVisibleAtOnce = (gS(0).w - 88) \ 48
FOR K = 1 TO nCount
IF nCount < nIconVisibleAtOnce + 1 THEN ' Center it on the Bar
IF K MOD 2 = 0 THEN
INCR nRight
gS(K).x = nCenter + (48 * nRight)
ELSE
gS(K).x = nCenter - (48 * nLeft)
INCR nLeft
END IF
ELSE
gS(K).x = 44 + (48 * (K - 1))
END IF
NEXT
END IF
'// Close process
CALL CloseHandle(hProcess)
END IF
END IF
END SUB
Geeh imo you are dealing with code you'll never keep up with.
'Progman'.., man, that's about 200 years old..
Then the assumption desktop's are kept being treated the same for long time by Windows?
If there isn't a solid api for it, better not pursuit it?
The purpose of the example was not about "progman" but the use of
VirtualAllocEx
OpenProcess
WriteProcessMemory
ReadProcessMemory
Anyway despite what you think, try this on Seven 64-bit
DECLARE FUNCTION FindWindow LIB "USER32.DLL" ALIAS "FindWindowA" (lpClassName AS ASCIIZ, lpWindowName AS ASCIIZ) AS LONG
FUNCTION PBMAIN
MSGBOX STR$(FindWindow("Progman", "Program Manager"))
END FUNCTION
Oh, yes i forgot that you are still running XP ;D
...
Of course there's legitimate needs for actual 64-bit code, but in your particular example, what are you exactly trying to do there? Specifically, if you want to create a shortcut, why aren't you just using the IShellLink interface? What you're doing there seems odd, and reading/writing memory for another process violates LUA (least privilege) principles.
Edit: If two processes want to share memory, there's specific APIs for that using memory-mapped files (i.e.: CreateFileMapping, MapViewOfFile, etc.) and they'll work between 32-bit and 64-bit processes. IMO, reading and writing the memory of another process, etc. should be an absolute last resort, particularly when that process is owned by the operating system. Even when code like that works today, I would always be concerned about it creating future compatibility problems. That said, I tend to be very conservative when it comes to this type of stuff.
It's not if progman still exists, it's being used during the old dde days for creating shortcuts, this progman stuff is simply still there but i don't think ms has given it carte blanche on keep on using it.
Like Progman.exe and control.exe (printerstuff) may still exist as well, they where there for backwards comp. reasons.
I am not trying to create a shortcut, but to retrieve all the info related to the shortcuts shown onto the desktop.
This is the code i am using now to deal with 64-bit:
SUB CreateShortCut(BYVAl hWnd AS LONG)
LOCAL nFound, nCount, nLeft, nRight, nHeight, hBitmap, xOffset AS LONG
LOCAL K, nItemCount, nCenter AS LONG, sLink, sUseThumb AS STRING
LOCAL rw AS RECT
gnXoffset = 0
'//gS(%ID_LEFT).visible = 0
'//gS(%ID_RIGHT).visible = 0
IF UBOUND(gS) > 0 THEN '// Clear existing bitmap
FOR K = 1 TO UBOUND(gS)
IF gS(K).hBitmap THEN DeleteObject(gS(K).hBitmap): gS(K).hBitmap = 0
NEXT
END IF
nCenter = (gS(0).w - 48) \ 2
ghProgMan = FindWindow("Progman", "Program Manager")
ghListView = FindWindowEx(ghProgMan, 0, "SHELLDLL_DefView", "")
ghListView = FindWindowEx(ghListView, 0, "SysListView32", "FolderView")
nItemCount = SendMessage(ghListView, %LVM_GETITEMCOUNT, 0, 0)
IF nItemCount THEN
LOCAL pWsh AS IWshShell
pWsh = NEWCOM "WScript.Shell"
LOCAL pLnk AS IWshShortcut
' Shortcut description: ACODE$(pLnk.Description)
' Shortcut working directory: ACODE$(pLnk.WorkingDirectory)
' Shortcut arguments: ACODE$(pLnk.Arguments)
' Shortcut hot key: ACODE$(pLnk.HotKey)
' Shortcut icon location: ACODE$(pLnk.IconLocation)
' Shortcut target path: ACODE$(pLnk.TargetPath)
' Shortcut window style: FORMAT$(pLnk.WindowStyle)
LOCAL sDeskTopPub, sDeskTopAdm, sFullName, sTempPath AS STRING
LOCAL DoLnk, nIconVisibleAtOnce AS LONG
LOCAL szTxt AS ASCIIZ * %MAX_PATH
'sDeskTopTray$ = zsFolderGet(&H000A) '// %CSIDL_BITBUCKET ' <desktop>\Recycle Bin
' %CSIDL_STARTMENU = &H000b ' <user name>\Start Menu
' %CSIDL_DESKTOPDIRECTORY = &H0010 ' <user name>\Desktop
sDeskTopAdm = zsFolderGet(%CSIDL_DESKTOP)
sDeskTopPub = zsFolderGet(%CSIDL_COMMON_DESKTOPDIRECTORY)
sTempPath = zGetTempPath()
CALL GetWindowRect(hWnd, rw)
nHeight = (rw.nBottom - rw.nTop) - 75
'// Do "Recycle bin" first
sTarget$ = "": szTxt = ShortCutDisplayName(%CSIDL_BITBUCKET): GOSUB ProcessPseudoLnk
gnRecycleBin = nCount': gS(gnRecycleBin).IconPath = EXE.Path$ + "UserIcon\48x48\RecycleBinFull.png"
IF gS(gnRecycleBin).hBitmap THEN DeleteObject(gS(gnRecycleBin).hBitmap): gS(gnRecycleBin).hBitmap = 0
sUseThumb = "RecycleBinEmpty.png": gnRecycleBinFull = 0
IF SHGetRecycleBinCount() THEN sUseThumb = "RecycleBinFull.png": gnRecycleBinFull = -1
gS(gnRecycleBin).IconPath = EXE.Path$ + "UserIcon\48x48\" + sUseThumb
gS(gnRecycleBin).hBitmap = CreateCustomIcon((gS(gnRecycleBin).IconPath), gS(gnRecycleBin).w, gS(gnRecycleBin).h, 0)
gS(gnRecycleBin).ShellTo = "explorer.exe"
gS(gnRecycleBin).CmdLine = "/N;::{645FF040-5081-101B-9F08-00AA002F954E}" '// "/N,::{645FF040-5081-101B-9F08-00AA002F954E}"
gS(gnRecycleBin).ShowCmd = %SW_SHOW
'// End Recycle bin
sFullName = sDeskTopAdm + "*.lnk"
slink = DIR$(sFullName, 39) ' %NORMAL + %READONLY + %HIDDEN + %SYSTEM + %ARCHIVE
DO WHILE LEN(sLink)
sFullName = sDeskTopAdm + sLink: GOSUB ProcessLnk
sLink = DIR$
LOOP
sFullName = sDeskTopPub + "*.lnk"
slink = DIR$(sFullName, 39) ' %NORMAL + %READONLY + %HIDDEN + %SYSTEM + %ARCHIVE
DO WHILE LEN(sLink)
sFullName = sDeskTopPub + sLink: GOSUB ProcessLnk
sLink = DIR$
LOOP
' ****************************************************
' Check for OTB file, and read/add custom shortcuts
CALL ReadCustomShortcuts(nFound, nCount, nHeight)
' ****************************************************
'// Setup icon x location
nIconVisibleAtOnce = (gS(0).w - 88) \ 48
xOffset = 44
IF nCount < nIconVisibleAtOnce + 1 THEN
xOffset += ((gS(0).w - 88) - (48 * nCount)) \ 2
END IF
FOR K = 1 TO nCount
gS(K).x = xOffset + (48 * (K - 1))
NEXT
END IF
EXIT SUB
ProcessLnk:
szTxt = PATHNAME$(NAME, sLink)
pLnk = pWsh.CreateShortcut(UCODE$(sFullName))
sTarget$ = RTRIM$(ACODE$(pLnk.TargetPath))
'af$ = sFullName +$cr + sTarget$ + $cr + _
' "Shortcut description: >" + ACODE$(pLnk.Description)+"<"+$cr+ _
' "Shortcut working directory: >" +ACODE$(pLnk.WorkingDirectory)+"<"+$cr+ _
' "Shortcut arguments: >" + ACODE$(pLnk.Arguments)+"<"+$cr+ _
' "Shortcut hot key: >" + ACODE$(pLnk.HotKey)+"<"+$cr+ _
' "Shortcut icon location: >" + ACODE$(pLnk.IconLocation)+"<"+$cr+ _
' "Shortcut target path: >" + ACODE$(pLnk.TargetPath)+"<"+$cr+ _
' "Shortcut window style: >" + FORMAT$(pLnk.WindowStyle)+"<"
'msgbox Af$
ProcessPseudoLnk:
DoLnk = -1
IF LEN(sTarget$) = 0 THEN
sTarget$ = ResolveShortcutName(szTxt)
IF LEN(sTarget$) = 0 THEN sTarget$ = ResolveLnk((sFullName)) ELSE DoLnk = 0
ELSEIF LCASE$(sTarget$) = LCASE$(EXE.FULL$) THEN
sTarget$ = ""
END IF
IF LEN(sTarget$) THEN
LOCAL sIconSearch AS STRING
sIconSearch = ""
IF DoLnk THEN sIconSearch = LCASE$(EXTRACT$(ACODE$(pLnk.IconLocation), ",")): IF RIGHT$(sIconSearch, 4) <> ".ico" THEN sIconSearch = ""
IF LEN(sIconSearch) = 0 THEN sIconSearch = sTarget$
INCR nFound
IF CreateBarIcon((sIconSearch), nFound) THEN
INCR nCount
REDIM PRESERVE gS(%LBOUND TO nCount)
gS(nCount).y = nHeight: gs(nCount).scale = %SCALE_DEFAULT: gS(nCount).opacity = 255
sUseThumb = sTempPath + "OfTheBay" + STR$(nFound) + ".png"
gS(nCount).hBitmap = CreateDockIcon((sUseThumb), gS(nCount).w, gS(nCount).h)
CALL zKillFile((sUseThumb))
IF DoLnk THEN gS(nCount).ShellTo = LCASE$(sTarget$)
IF DoLnk THEN gS(nCount).WorkDir = ACODE$(pLnk.WorkingDirectory)
IF DoLnk THEN gS(nCount).CmdLine = ACODE$(pLnk.Arguments)
gS(nCount).UseLabel = szTxt
IF DoLnk THEN gS(nCount).ShowCmd = pLnk.WindowStyle
'// Check for "My computer"
IF gS(nCount).UseLabel = ShortCutDisplayName(%CSIDL_DRIVES) THEN
gS(nCount).ShellTo = "explorer.exe"
gS(nCount).CmdLine = "/N;::{20d04fe0-3aea-1069-a2d8-08002b30309d}" '// "/N,::{20d04fe0-3aea-1069-a2d8-08002b30309d}"
gS(nCount).ShowCmd = %SW_SHOW
END IF
END IF
END IF
RETURN
END SUB
This was just to give an example of the first problem i had to solve, because my program was 32-bit and the OS was 64-bit.
Note: Don't be fool by the name of the procedure CreateShorCut it is not doing what you think, indeed it is something very different that the ishelllink interface.
What i am using here is the Active Desktop Object as explained here:
http://msdn.microsoft.com/en-us/library/bb776830(VS.85).aspx (http://msdn.microsoft.com/en-us/library/bb776830(VS.85).aspx)
If you want to figure what this program is doing, then download the GDImage project "Of The Bay" and you will get the picture ;)
Before (the Windows look)
(http://www.zapsolution.com/DW/images/OTB/P_desktop.jpg)
After (the Mac OSX look)
(http://www.zapsolution.com/DW/images/OTB/P_ofthebay.jpg)
...
Mike,
Do you know the correct C# syntax to use fixed to pass a pointer on an array structure to an unmanaged DLL ?
...
If you want to pin variables, then you need to declare the code as unsafe. Here's a very simple example of using a pointer to an array.
class Program
{
static void Main(string[] args)
{
int[] fooBar = new int[5];
for (int i = 0; i < 5; i++)
{
fooBar[i] = i + 1;
Console.WriteLine("fooBar[{0}] = {1}", i, fooBar[i]);
}
Console.WriteLine("----");
// if you want to pin variables and manipulate pointers to them,
// then you need to declare the code unsafe
unsafe
{
fixed (int* pBar = fooBar)
{
// the array is pinned and cannot be moved by the garbage collector,
// you can change the value of what is being pointed to
for (int i = 0; i < 5; i++)
pBar[i] += 10;
// You could call your unmanaged code here, passing in pBar as
// the pointer to the array
Console.WriteLine("fooBar[3] = {0}", *(pBar + 3));
}
}
Console.WriteLine("----");
for (int i = 0; i < 5; i++)
Console.WriteLine("fooBar[{0}] = {1}", i, fooBar[i]);
}
}
By the way, although that example is clearly contrived, keep in mind that you'll need to leave that array (or whaever you're passing a pointer to) pinned as long as your unmanaged code hangs on to it. What you generally do not want to do is have your unmanaged code "store" that pointer anywhere (in a context structure, global, etc.) and keep referencing it, forcing the data to be pinned for long periods of time. If you do really want to lock down a managed object, then you can use GCHandle.Alloc but it's basically the same issue; long-term pinning of objects inteferes with garbage collection so you want to keep that to a minimum.
Mike,
Here is the PB code:
TYPE ZGLTEXTUREX
ID AS LONG
FullName AS ASCIIZ * 260
Texture AS LONG
Square AS LONG '// boolean TRUE or FALSE value
END TYPE
Translated to C#:
[StructLayout(LayoutKind.Sequential)]
public struct ZGLTEXTUREX
{
public int ID;
[MarshalAs(UnmanagedType.ByValTStr, SizeConst = Api.MAX_PATH)]
public string FullName;
public int Texture;
public int Square;
}Then i am creating the C# array this way
static GI.ZGLTEXTURE[] mt = new GI.ZGLTEXTURE[3]and I would like to call this PB function
DECLARE FUNCTION ZI_MakeMultipleTexture ALIAS "ZI_MakeMultipleTexture" (BYVAL mt AS ZGLTEXTUREX PTR, BYVAL tArrayCount AS LONG) EXPORT AS LONGNote: The whole project is declared "unsafe".
Should i declared the
GI.ZGLTEXTURE[] mt array this way:
fixed (int* pmt = mt)and how should i declare the ZI_MakeMultipleTexture (see the ? ? ? ?)
Quote[DllImport(GDIMAGE, EntryPoint = "ZI_MakeMultipleTexture")]
public static extern int MakeMultipleTexture(? ? ? ?, int n);
Off the top of my head, I think something like this will do what you want. I modifed the structure to use a fixed byte array because the way that you had declared it, it was not a blittable type and GCHandle wouldn't be able to pin it. The only inconvenience there is that you'll need to create a helper to read/write the FullName member of the structure, rather than simply assigning it a value and let the marshaling code take care of it.
unsafe public struct ZGLTEXTUREX
{
public int ID;
public fixed byte FullName[260]; // or whatever the size actually is
public int Texture;
public int Square;
}
[DllImport("whatever.dll", EntryPoint = "ZI_MakeMultipleTexture")]
public static extern int ZI_MakeMulitpleTexture(
IntPtr mt,
int tArrayCount
);
ZGLTEXTUREX[] mt = new ZGLTEXTUREX[3];
GCHandle gchmt = GCHandle.Alloc(mt, GCHandleType.Pinned); // array is pinned and cannot be GCed
result = ZI_MakeMultipleTexture(gchmt.AddrOfPinnedObject(), 3);
// do whaever else, at some point later when that structure array is no
// longer needed, make sure you free it so that it can be GCed
gchmt.Free();
Thank you Mike, i will give it a try.
The infamous GC is the thing that discouraged me to make further advanced graphic programming in C#. >:(
...
Quote from: Patrice Terrier on July 12, 2010, 05:40:40 PM
The infamous GC is the thing that discouraged me to make further advanced graphic programming in C#.
What you might want to consider doing is create "helper functions" that you can use in C# so that you don't have to create objects in the managed address space and then pin them. So instead of creating an array of structures, pinning it and passing a pointer, you could create some additional functions, something like: ZI_AllocMultipleTextures (allocate memory for the array, return a pointer to the base element of the array), ZI_InitializeTexture (to set the structure members), and ZI_FreeTextures (to release the memory you've allocated).
This kind of approach could have a couple of advantages. First, you could treat the return value from ZI_AllocMultipleTextures as opaque; it would be a pointer (IntPtr in C#) but it would just be a value that you could store and pass around without worrying about pinning, etc. It also would also mean that your C# code wouldn't need to to worry about what exactly the ZGLTEXTURE structure "looks like" since you would only be dealing with it using accessor functions; if you changed it in your PB code, you wouldn't have to worry about also making the corresponding change in your C# code.
I realize I'm a little late to this dance but I noticed BCX was being
discussed earlier in this thread and thought it would be helpful to
share a perspective from Armando Rivera. Armando has been making
inroads into making native code applications for MacOSX using BCX.
(See scrnshot)
NB: I appreciate the mature attitude allowing discussion of other
languages (like BCX) on this board, versus the PowerBasic policy that
says competing products cannot be discussed. Oddly, the recent
discussion about RealBasic on PB's forum escaped the forum police,
probably because most of the posts about RealBasic were negative :D
Thank you.
Armando Rivera
BCX Developer
Why I Like BCX « on: September 06, 2009, 05:29:31 AM »
Flexibility. Power. The merging of two disparate core languages, C and Basic.
It eliminates one of my Major gripes with Basic languages: Having to create
Include files in order to use external libraries. I've always been more of an
implementer vs an Application coder, so this is real important to me.
Granted, there are Basic languages whose teams have done a phenomenal job of translating
C Header files (FreeBasic comes to mind), but the thing that's always bugged me
is that the C Header files are already there! I just needed a Basic that could use
them as is.
BCX is the answer, for me anyway. It's a huge relief not having to translate C
code to Basic too, since I can just plug it in when I need to.
I've also learned a LOT by studying it's output.
Some say that it's simply a translator, but in the end EVERY language is.
In this day of ever abstracting languages, that take you further and further away
from the generated code, it's such a pleasure to be able to see what I've coded
translated into something that is fairly easy to follow, with minimal bloat. Because
of that, I've gained a much deeper understanding and appreciation for the C language.
In other Basic porting projects that I'd worked on, I always had to contend with major
resistance to using C to speed up the porting process. Since BCX is built from the
ground up to use C as it's core it's been real fun to use and tinker with. All you
have to do is look at how quickly the Linux GUI came together to see the benefits
of using this approach. Yeah, I know it's not finished but it's still very usable.
To summarize, BCX works because it "Just Works". Being able to merge Basic and C
syntax in the same source is an awesome boost to my work flow.
AIR.
Kev,
While PowerBASIC is heavily used by most of those posting here, it is not the only language we are are using on this forum.
For example in my dedicated section you will find code for C#, C++, WinDev, and third party addon examples.
Most of us, have also a very good insight of the C programming language, because we use the core Windows SDK flat API, instead of API encapsulation.
As a third party addon provider, i feel more concerned by Visual Studio and WinDev, because they are the largest professional market for my tools (understand, people using VS and WD are used to pay for the tools they are developing with ;) ).
However, for those programming for themselves, or wanting to produce code for other platforms, BCX looks like a very good chalenger, especialy for those who are familiar with the BASIC syntax.
Thus, you are welcomed here!
...