first off, I really need to make a 64bit version of glfwdll.a and glfw.dll (so I can hopefully finally succeed in getting the Go glfw bindings to work under Windows ... was a breeeeze under Linux!)
Seems like I now succeeded in compiling 64bit versions of glfwdll.a and glfw.dll using mingw64, MSYS and their make scripts, even though I did get a couple of error messages along the lines of "maincrt entry point not found, using default 0xsomehexnumber instead" or some such. Entry points of course refer to executables, in this case those in the examples directory.
And indeed, most of them don't work! All got built however. The following executables work:
listmodes.exe mtbench.exe mthello.exe and particles.exe -- the latter being the only graphical (3d gfx) example working for me (the former ones just outputting some test infos onto the console window).
Now what's the issue with the other ones? They don't crash, they don't report anything to the console... I run them, they return immediately, silently.
Is my GLFW build broken? How to fix? What's the big difference between the 4 examples that work and the others that don't?
This is a fairly new, vanilla Win7 64bit installation. No crapware, everything up to date, UAC and Themes are off, not a lot of software installed at all, Nvidia GPU driver updated (GPU Caps Viewer and the likes run fine, so OpenGL is there).
I'm not yet allowed to add comments, so I'll post this as an answer.
The issue you're having is due to three separate bug in GLFW. I fixed them today and the fixes will be included in GLFW 2.7.6. Until then, you can use trunk from the GLFW Subversion repository.
To be sure that you really have no DLL-hell issues with the opengl32.dll, glu32.dll, glut32.dll etc., check out the Event Viewer tool and see if there are some warnings or errors for you app.
This is my thought because you are only able to run the mtbench and mthello which have nothing in common with the "real" OpenGL API.
No clue about particles.exe though - maybe GLFW checks for errors internally and call the exit() routine ? Check the %errorlevel% also.
Also take a look here:
http://glfw.svn.sourceforge.net/viewvc/glfw/trunk/examples/pong3d.c?revision=1110&view=markup
There is a GameMenu() function which may exit silently if "!glfwGetWindowParam( GLFW_OPENED )", which obviously means that OpenGL was not initialized.
The same function serves as an exit flag here
http://glfw.svn.sourceforge.net/viewvc/glfw/trunk/examples/wave.c?revision=1110&view=markup
Once again, double-check the DLLs !
I believe that you are experienced not to make "advanced" mistakes in the build process, so there just might be some funny thing happening at the "user level".
And another suggestion:
http://sourceforge.net/projects/glfw/forums/forum/247562/topic/3868944
Some parameters might not work exactly for you.
To "fix" the samples try commenting out the glfwGetWindowParam call.
Related
Not a programming problem per se, but rather a programming environment problem that I have been unable to find a solution to.
The problem relates to Adobe's Extendscript Toolkit (both 3.5 and 4), but so far I haven't been able to solve the problem, so here I am...
The error I get has appeared more or less over night. I didn't experience this problem yesterday, nor this morning. But exactly WHAT has happened is beyond me. I have removed preferences, I have uninstalled, reinstalled, created a new user, restored old preferences from Time Machine and I'm now pretty much lost for options.
Basically, nothing works in ESTK anymore. Just opening ESTK and entering alert('Hello') won't work. Neither will $.writeln(). Everything running from within ESTK seems to give the same error;
Cannot execute script in target engine 'main'
With details:
Cannot execute script in target engine 'main'!
(#1116) Can't start debug session.
Below is a screenshot taken from the new user I created to test, same problem.
The "funny" thing is that all the scripts (InDesign CS5, still hanging on to it for reasons) still work perfectly in the applications' script panels. So there is nothing wrong with the scripts (heck, they haven't changed one bit, and still refuses to run in ESTK).
As mentioned, I've tried installing the ESTK CC (version 4) as well, but the very same problem occurs there. Which leads me to think the problem lies somewhere else, but I do not know where, and why.
So, if anyone can shed any light on this issue, at all, I would be very happy. Debugging is basically the only thing ESTK is good for in my book, but now that even that functionality is gone, I don't know how to efficiently debug the scripts which is kind of hampering the workflow.
For reference, I'm running InDesign CS5 (from the old Creative Suite) on a 2008 Mac Pro with 10.11.6 (El Capitan) installed. Well aware that it's pretty out of date, but that is beside the point here.
In the above mentioned forum, Adobe has published a stable workaround!You just have to correct a setting inside the estk application:
Open the file(Mac): “/Applications/Adobe ExtendScript Toolkit CC/ExtendScript Toolkit.app/Contents/SharedSupport/Required/cdic/11BTBackend.jsx”
Search for the value: 604800000 (line reads bt.timeout = 604800000)
Replace that value with 604800 and save
Quit ExtendScript Toolkit and relaunch.
I can confirm that it works.
From the adobe Forum :
"we have found a first workaround: just change your date to any date before 20-nov-2018"
https://forums.adobe.com/message/10761440#10761440
Seems like a date issue :(
I just published a quick update about this on the Adobe Tech Blog.
For the time being, if you dismiss the dialog, you can still run your script via ESTK and step through code as usual.
Alternatively, if you really want to avoid the dialogs, and you don’t mind setting your clock back, you can sidestep the issue by setting your system clock back to November 19, 2018 or before. On most systems, changing the system time can have unintended side effects, so this isn’t recommended unless you’re really certain about it.
I use gopacket in my program. on linux, it runs perfectly.
But on windows the whole program crashes if i did not install WinPcap before.
My plan was to check if WinPcap is installed, and if not to inform the user that he needs this to use 100% of all features.
But i dont come to this point. i cant use gopacket if WinPcap is not available. I mean... not a single line of code of it (=> crash)
Has anyone an idea how i can solve this? im do not need gopacket actually. My plan was, if it is installed, fine, super! If not, dont care... do other things.
But now i have 2 choices... remove gopacket totally or find a way to start my program without the need of wpcap.dll. at least to tell the user that he needs it.
Please help me :(
You're wrong in that you are «not [using] a single line of code of it»: it's not hard to see that
its Windows-specific code calls into winpcap.dll.
What is more fun, is that
its Unix-specific code calls into libpcap.so, and this means you have it working on your local system simply due to the fact you have libpcap package installed (or whatever it's named in your code).
All this means that currently your program is not really portable
anyway (I mean, in the sense you supposedly think it is portable).
You can run something like
$ ldd ./yourbinary
and see it printing a reference to libpcap.so of some version.
There are several ways to solve this.
The easiest is to just try shipping winpcap.dll with your binary. Windows by default looks for DLLs in the current directory of the application trying to load them. Since gopacket uses cgo, it means the winpcap.dll is attempted to be linked it at the application startup, so the application has no chance of changing its working directory before that library is attempted to be found and linked in.
A more complicated approach is to make (or obtain) a static version of the winpcap library (remember that DLL is a library, just a special form of it) and then jump around building gopacket so that it picks that static library.
Install Npcap in "Wpcap API compatibility mode".
I have a 32-bit application and I have a problem with it on Windows 7 x64. I'm loading a DLL. LoadLibraryW succeeds and the subsequent call to GetProcAddress fails with the error code 127 ("procedure not found" or something like that).
The funny part is that I know for a fact the function is exported by the DLL. I made no typos in the GetProcAddress call. I can see the function with Depends.exe and DllExp.exe. The exact same application binary successfully loads the function from the exact same DLL on Windows 10 x64, but not on Windows 7 x64.
Some more details: the library is dbghelp.dll and the "missing" function is MiniDumpWriteDump.
And the fun bit: dbghelp.dll provides API for inspecting the modules loaded into the process and for enumerating functions exported by those modules. So, first I took the HMODULE for this problematic dbghelp.dll and ran
auto ptrSymInitialize = (decltype(&SymInitialize))GetProcAddress(hDbgHelpDll, "SymInitialize");
It worked, this function did load! Then I loaded SymEnumSymbols, written the enumerator callback and finally ran the following to enumerate all the functions in this very `dbghelp.dll":
ptrSymEnum(GetCurrentProcess(), 0, "dbghelp*!*", &Enumerator, nullptr);
And what do you know, MiniDumpWriteDump is, in fact, listed there. Go figure.
Thoughts?
I can see your intent is to use MiniDumpWriteDump. We also make minidumps in our product, and I'm the one to support this.
I would suggest against using dbghelp.dll supplied with OS. First, they tend to be outdated and not support the latest minidump capabilities, which you would want to have. Second, they have proven to be rather unreliable. I believe they simply lack too many bugfixes.
What I found to work quite well is to take dbghelp.dll from Debugging Tools for Windows package (currently part of Windows SDK) and ship it along with our product. This way, I can be sure minidumps will have all the latest features and it works reliably on all OS. It has been some 8 years now, with OS ranging from WinXP to Win10, and I didn't have any issues.
I'm not exactly sure which version of SDK I used to extract the currently used dbghelp.dll, probably it was Win7 SDK. I simply didn't have a reason to update since then. However, we do use Debugging Tools for Windows package from Win10 SDK on Win7 without any issues, so I guess you can use Win10 version as well.
that's exactly what I've been doing, and I didn't bring dbgcore.dll
This was just a plain bad idea. Microsoft makes no effort to make the DLLs that are included with the OS to be backwards compatible. They don't have to. In their implementation, only the interface needs to be compatible. They do take advantage of new capabilities or design changes to improve the implementation.
Like you saw here, a side-effect of the MinWin project. There is no reasonable guess where that ended, if it happens to work now on the Win7 machine then you got lucky. Maybe you won't be so lucky on a Win7 machine without SP1, maybe some minwin glue DLLs are missing on a clean install, maybe the minidump itself is affected negatively some way. Impossible to predict.
So never do this. Afaik you should not be doing this at all, a Win7 machine already has dbghelp.dll available. Not 100% sure, it has been too long and Win7 is rapidly turning into the new XP. If you find it to be necessary then always use the redistributable version. Included with the SDK's Debugging Tools for Windows. Copy it into the same folder as the EXE that needs it so you don't mess up a machine.
I have a GCC 3.4.3 toolchain built for ARM (arm-elf) here in my Windows 7 (64bits) setup. We use this to build our software product to a specific hardware.
Recently, we have been experiencing some problems with this particular toolchain.
First, when we try to call arm-elf-gcc to build each source file (there are lots of them), it complained about it not being able to allocate enough heap.
Then, I thought it was some problem with the outdated cygwin DLL distributed by the hardware vendor. So I replaced it with a more recent version (1.7.35). The problem stopped and the build does go ok but now it is incredibly SLOW (it took about 40s to build a single .c source file).
Does anyone has experienced this problem before? How can I debug and fix it?
Thanks in advance.
Sounds like you have had a similar problem to me and might be worth trying this. When i first encountered this, I had to install cygserver and then run this (make sure you right click admin):
Previous solution
However, the problem resumed and I simultaneously couldn't install/uninstall some problems. Eventually I resolved this by terminating SearchIndexer.exe in Task Manager. Indeed, I have gone in to Control Panel / Searach Indexing and pulled it back from doing any indexing. My installation taking 1hr took 3 more seconds. The change to Cygwin was instantaneous.
Cygwin is now flying!
I've had an issue with slow execution of builds for a while on cygwin, using make and a proprietary compiler that "isn't gcc, honest...", but has very similar error returns.
I was forced to update yesterday and ran into the issue of rebaseall simply failing to execute. This forced me to dig into other things and I found a report that Trusteer Rapport/End Point Protection has been known to cause issues with rebaseall,and slow response times. So I removed it. This fixed the rebaseall, but has also massively increased the speed of my build. Worth checking to see if you have it installed, try removing it. AV packages in general are reputed to interfere and may be the cause.
I have some customers/candidate who complained that my program doesn't work on their Windows 7 64 bit version (confirmed with screenshots). The errors were strange, for example:
in the trial version i am
getting a error message whenever i
click on \"mark\" \"delete\" \"help\".
error msg is: Access violation at
address 0046C978 in module
\'ideduper.exe.\' read of address
00000004
windows 7 ultimate 64bit. i7 920
#2.67GHz 9gb or ram
'Mark', 'delete' and 'help' are just standard TToolButton on TToolbar.
The other example is failing to get a thumbnail from IExtractImage.
I have told them to try Compatibility mode but still doesn't work.
The problem is when I tested it on Windows 7 HP 64-bit on my computer (which I've done it before released it actually) it just works fine! So I don't know what causing it
Do you have any advice ?Are different Windows package (home basic,premium,ultimate,etc) treating 32 bit prog differently ?Are the newer version of Delphis (I use 2006) more compatible with 64 bit Windows ? Do I need to wait until 64 bit compiler out?
Thanks in advance
Your best bet in my opinion is to add MadExcept or EurekaLog or something similar to your application and give it to the customer to try again. MadExcept will generate log with stack trace, which will give you a clearer view of what is happening there.
To answer 2nd part of the question, 32bit Delphi programs work fine on 64bit Windows 7. I think it's more likely you have some memory management problems and the customer just happens to stumble upon them while you don't. Use FastMM4 to track those down.
Your applications is trying to access an invalid pointer. Changing environment may surface issues that are hidden in others. Check your application, and use FastMM + JCL+JCVL/MadExcept/EurekaLog to get a detailed trace of the issue. Some Windows APIs may have some stricter call requisites under 7 and/or 64 bit, but we would have to know what your app actually cals.
A free alternative to MadExcept is JCL Debug stuff. However it is less thorough and doesn't include the cool dialog box to send the stack trace to you via email, or as a file you can attach and manually email.
MadExcept is worth the money, and it is free for non-commercial use. You could try it first on your own PC, observe its functionality, and be sure it functions the way you want, and then buy it.
If buying Delphi is worth it (and it is!) then buying mad Except is a no brainer. But if you insist on rolling your own, JCLDebug (part of jedi code library) is also pretty nice.
Give them a stripped down version of your app and see when the problem goes away. I am betting it is your code as I never had any problems with my (hundreds of) W7/64 clients.
I'd be willing to bet it's an issue in your code. The reason it's failing on your customer's machine and not yours is that your machine probably has the default Data Execution Protection (DEP) enabled (which is turned on only for essential Windows programs and services), while your customer's computer is actually using DEP as intended (turned on for all programs and services).
The default setting (which is compatible with older versions of Windows, like 95/98/ME), allows software to execute code from what should be data segments. The more strict setting won't allow this, and raises a system-level exception instead.
You can check the settings between the two by looking at System Properties. I'm not at a Win7 machine right now, but on WinXP you get there by right-clicking on My Computer, choosing Properties, clicking on Performance Options, and then selecting the "Data Execution Prevention" tab. Find it on Vista/Win7 by using the Help; search for Data Execution Protection.
The solution, as previous answers have told you, is to install MadExcept or EurekaLog. You can also get a free version as part of JEDI, in JCLDebug IIRC. I haven't used it, so I can't vouch for it personally. I've heard it's pretty good, though.
If you don't want to go that route, set a breakpoint somewhere in the startup portion of your app (make sure to build with debugging info turned on). Run your app until the breakpoint is hit, and then use the IDE's Search->Goto Address (which is disabled until the breakpoint is hit). Enter the address from the exception dialog (not the one that's almost all zeros, but the 0046C978 address, prefixed with $ to indicate it's in hex) as in $0046C978. You'll probably end up in the CPU window looking at assembly code, but you can usually pick out a line of Delphi code of some sort that can sometimes give you a place to start looking.
In addition to all previous suggestions, I'll add the difference in accessing Registry under WOW64 compared to Win32. If your application is accessing Registry to read or write some settings, you should be aware of this. First, take a look at this and this page in the MSDN. On this page you will find 2 flags that determine the access you get to Registry from 32- or 64-bit application. KEY_WOW64_64KEY is the one that you should use.
In any case, I agree with others about using madExcept (or any other similar tool) to be able to find the exact cause of your problems.